Merge "mvebu defconfig for arm64 for 4.7" from Gregory CLEMENT:
- update arm64 defconfig with options useful for Armada 7K/8K support
* tag 'mvebu-defconfig64-4.7-1' of git://git.infradead.org/linux-mvebu:
arm64: configs: add options useful for Armada 7K/8K support
The kernel headers package (linux-headers) doesn't include
header files from other architectures required to build
out-of-tree modules.
For e.g. on ARM64, opcodes.h includes the same file from ARM
which causes the following error:
./arch/arm64/include/asm/opcodes.h:1:43: fatal error:
../../arm/include/asm/opcodes.h: No such file or directory
compilation terminated.
Signed-off-by: Azriel Samson <asamson@codeaurora.org>
Signed-off-by: Michal Marek <mmarek@suse.com>
"objtool" is required for building external m dules if "Compile-time
stack metadata validation" is enabled. Otherwise all builds based
on the headers package fail with:
make[1]: Entering directory '/usr/src/linux-headers-4.6.0-rc6'
make[2]: *** No rule to make target 'tools/objtool/objtool', needed by 'foo.o'. Stop.
Makefile:1598: recipe for target 'foo.ko' failed
make[1]: *** [foo.ko] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-4.6.0-rc6'
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Michal Marek <mmarek@suse.com>
Support sending P2P device frames should be sent from
queue #2, as required in DQA mode.
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
The type of a choice can be specified explicitely or it will be
set according to members of the choice group, see menu.c:menu_finalize().
Signed-off-by: Dirk Gouders <dirk@gouders.net>
Signed-off-by: Michal Marek <mmarek@suse.com>
In the given example, the comment becomes visible when it's dependency
is set to 'n', but the text asserts the opposite.
Signed-off-by: Dirk Gouders <dirk@gouders.net>
Signed-off-by: Michal Marek <mmarek@suse.com>
When only one symbol was listed and therefore the line didn't contain
any space to separate multiple symbols, that symbol got ignored.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Michal Marek <mmarek@suse.com>
In kernel/cgroup.c there is:
#define SUBSYS(_x) \
DEFINE_STATIC_KEY_TRUE(_x ## _cgrp_subsys_enabled_key); \
DEFINE_STATIC_KEY_TRUE(_x ## _cgrp_subsys_on_dfl_key); \
EXPORT_SYMBOL_GPL(_x ## _cgrp_subsys_enabled_key); \
EXPORT_SYMBOL_GPL(_x ## _cgrp_subsys_on_dfl_key);
The expansion of this macro causes multiple EXPORT_SYMBOL_GPL() instances
to appear on the same preprocessor line output, confusing the sed script
expecting only one of them per line. Unfortunately this can't be fixed
nicely in the sed script as sed's regexp can't do non greedy matching.
Fix this by turning any semicolon into a line break before filtering.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Michal Marek <mmarek@suse.com>
If the .config parser runs into unexpected data it emits warnings like:
.config:6911:warning: unexpected data
Add the unexpected data itself to this warning. That makes it easier to
discover what is actually going wrong:
.config:6911:warning: unexpected data: CONFOG_CHARGER_TPS65217=m
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Michal Marek <mmarek@suse.com>
When gcov profiling is enabled, we see a lot of spurious warnings about
possibly uninitialized variables being used:
arch/arm/mm/dma-mapping.c: In function 'arm_coherent_iommu_map_page':
arch/arm/mm/dma-mapping.c:1085:16: warning: 'start' may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/clk/st/clk-flexgen.c: In function 'st_of_flexgen_setup':
drivers/clk/st/clk-flexgen.c:323:9: warning: 'num_parents' may be used uninitialized in this function [-Wmaybe-uninitialized]
kernel/cgroup.c: In function 'cgroup_mount':
kernel/cgroup.c:2119:11: warning: 'root' may be used uninitialized in this function [-Wmaybe-uninitialized]
All of these are false positives, so it seems better to just disable
the warnings whenever GCOV is enabled. Most users don't enable GCOV,
and based on a prior patch, it is now also disabled for 'allmodconfig'
builds, so there should be no downsides of doing this.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Michal Marek <mmarek@suse.com>
Enabling CONFIG_GCOV_PROFILE_ALL produces us a lot of warnings like
lib/lz4/lz4hc_compress.c: In function 'lz4_compresshcctx':
lib/lz4/lz4hc_compress.c:514:1: warning: the frame size of 1504 bytes is larger than 1024 bytes [-Wframe-larger-than=]
After some investigation, I found that this behavior started with gcc-4.9,
and opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69702.
A suggested workaround for it is to use the -fno-tree-loop-im
flag that turns off one of the optimization stages in gcc, so the
code runs a little slower but does not use excessive amounts
of stack.
We could make this conditional on the gcc version, but I could not
find an easy way to do this in Kbuild and the benefit would be
fairly small, given that most of the gcc version in production are
affected now.
I'm marking this for 'stable' backports because it addresses a bug
with code generation in gcc that exists in all kernel versions
with the affected gcc releases.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Michal Marek <mmarek@suse.com>
Enabling gcov is counterproductive to compile testing: it significantly
increases the kernel image size, compile time, and it produces lots
of false positive "may be used uninitialized" warnings as the result
of missed optimizations.
This is in line with how UBSAN_SANITIZE_ALL and PROFILE_ALL_BRANCHES
work, both of which have similar problems.
With an ARM allmodconfig kernel, I see the build time drop from
283 minutes CPU time to 225 minutes, and the vmlinux size drops
from 43MB to 26MB.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Michal Marek <mmarek@suse.com>
CONFIG_PROFILE_ALL_BRANCHES confuses gcc-5.x to the degree that it prints
incorrect warnings about a lot of variables that it thinks can be used
uninitialized, e.g.:
i2c/busses/i2c-diolan-u2c.c: In function 'diolan_usb_xfer':
i2c/busses/i2c-diolan-u2c.c:391:16: warning: 'byte' may be used uninitialized in this function
iio/gyro/itg3200_core.c: In function 'itg3200_probe':
iio/gyro/itg3200_core.c:213:6: warning: 'val' may be used uninitialized in this function
leds/leds-lp55xx-common.c: In function 'lp55xx_update_bits':
leds/leds-lp55xx-common.c:350:6: warning: 'tmp' may be used uninitialized in this function
misc/bmp085.c: In function 'show_pressure':
misc/bmp085.c:363:10: warning: 'pressure' may be used uninitialized in this function
power/ds2782_battery.c: In function 'ds2786_get_capacity':
power/ds2782_battery.c:214:17: warning: 'raw' may be used uninitialized in this function
These are all false positives that either rob someone's time when trying
to figure out whether they are real, or they get people to send wrong
patches to shut up the warnings.
Nobody normally wants to run a CONFIG_PROFILE_ALL_BRANCHES kernel in
production, so disabling the whole class of warnings for this configuration
has no serious downsides either.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Steven Rostedt <rostedtgoodmis.org>
Signed-off-by: Michal Marek <mmarek@suse.com>
CC_OPTIMIZE_FOR_SIZE disables the often useful -Wmaybe-unused warning,
because that causes a ridiculous amount of false positives when combined
with -Os.
This means a lot of warnings don't show up in testing by the developers
that should see them with an 'allmodconfig' kernel that has
CC_OPTIMIZE_FOR_SIZE enabled, but only later in randconfig builds
that don't.
This changes the Kconfig logic around CC_OPTIMIZE_FOR_SIZE to make
it a 'choice' statement defaulting to CC_OPTIMIZE_FOR_PERFORMANCE
that gets added for this purpose. The allmodconfig and allyesconfig
kernels now default to -O2 with the maybe-unused warning enabled.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Michal Marek <mmarek@suse.com>
When snd_pcm_add_chmap_ctls() is called to the PCM stream to which a
chmap has been already assigned, it returns as an error due to the
conflicting snd_ctl_add() result. However, this also clears the
already assigned chmap_kctl field via pcm_chmap_ctl_private_free(),
and becomes inconsistent in the later operation.
This patch adds the check of the conflicting chmap kctl before
actually trying to allocate / assign. The check failure is treated as
a kernel warning, as the double call of snd_pcm_add_chmap_ctls() is
basically a driver bug and having the stack trace would help
developers to figure out the bad code path.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In former commit, drivers in ALSA firewire stack always starts IT context
before IR context. If IR context starts after packets are transmitted by
peer unit, packet discontinuity may be detected because the context starts
in the middle of packet streaming. This situation is rare because IT
context usually starts immediately. However, it's better to solve this
issue. This is suppressed with CIP_SKIP_INIT_DBC_CHECK flag.
This commit enables the same feature as CIP_SKIP_INIT_DBC_CHECK.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In previous commit, this module has no need to reuse parameters of
incoming packets for outgoing packets anymore. This commit arranges some
needless codes for outgoing packet processing.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In previous commit, this module has no need to reuse parameters of
incoming packets for outgoing packets anymore. This commit arranges some
needless codes for incoming packet processing.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In clause 6.3 of IEC 61883-6:2000, there's an explanation about processing
of presentation timestamp. In the clause, we can see "If a function block
receives a CIP, processes it and subsequently re-transmits it, then the
SYT of the outgoing CIP shall be the sum of the incoming SYT and the
processing delay." ALSA firewire stack has an implementation to partly
satisfy this specification. Developers assumed the stack to perform as an
Audio function block[1].
Following to the assumption, current implementation of ALSA firewire stack
use one software interrupt context to handle both of in/out packets. In
most case, this is processed in 1394 OHCI IR context independently of the
opposite context. Thus, this implementation uses longer CPU time in the
software interrupt context. This is not better for whole system.
Against the assumption, I confirmed that each ASIC for IEC 61883-1/6
doesn't necessarily expect it to the stack. Thus, current implementation
of ALSA firewire stack includes over-engineering.
This commit purges the implementation. As a result, packets of one
direction are handled in one software interrupt context and spends
minimum CPU time.
[1] [alsa-devel] [PATCH 0/8] [RFC] new driver for Echo Audio's Fireworks based devices
http://mailman.alsa-project.org/pipermail/alsa-devel/2013-June/062660.html
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In packet streaming protocol applied to TASCAM FireWire series, the value
of SYT field in CIP header is always zero, therefore it has no meaning.
There's no need to synchronize packets in both direction for the series.
In current implementation of ALSA firewire stack, driver for the series
uses incoming packet parameter for outgoing packet parameter to calculate
the number of data blocks. This can be simplified because the task of
corresponding driver is to transfer data blocks enough to sampling transfer
frequency.
This commit purges support of full duplex synchronization to prevent
over-engineering implementation.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
On Fireworks board module of Echo Audio, TSB43Cx43A (IceLynx Micro, iCEM)
is used to process payload of isochronous packets. There's an public
document of this chip[1]. This document is for firmware programmers to
transfer/receive AMDTP with IEC60958 data format, however in clause 2.5,
2.6 and 2.7, we can see system design to utilize the sequence of value in
SYT field of CIP header. In clause 2.3, we can see the specification of
Audio Master Clock (MCLK) from iCEM.
Well, this clock is actually not used for sampling clock. This can be
confirmed when corresponding driver transfer random value as the sequence
of SYT field. Even if in this case, the unit generates proper sound.
Additionally, in unique command set for this board module, the format
of CIP is changed; for IEC 61883-6 mode which we use, and for Windows
Operating System. In the latter mode, the whole 32 bit field in second CIP
header from Windows driver is used to represent counter of packets (NO-DATA
code is still used for packets without data blocks). If the master clock
was physically used by DSP on the board module, the Windows driver must
have transferred correct sequence of SYT field.
Furthermore, as long as seeing capacities of AudioFire2, AudioFire4,
AudioFire8, AudioFirePre8 and AudioFire12, these models don't support
SYT-Match clock source.
Summary, we have no need to relate incoming/outgoing packets. This commit
drops reusing SYT sequence of incoming packets for outgoing packets.
[1] Using TSB43Cx43A: S/PDIF over 1394 (2003, Texus Instruments
Incorporated)
http://www.ti.com/analog/docs/litabsmultiplefilelist.tsp?literatureNumber=slla148&docCategoryId=1&familyId=361
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Windows driver for BeBoB-based models mostly wait for transmitted packets,
then transfer packets to the models. This looks for the relationship
between incoming packets and outgoing packets to synchronize the sequence
of presentation timestamp.
However, the sequence between packets of both direction has no
relationship. Even if receiving NO-DATA packets, the drivers transfer
packets with meaningful value in SYT field. Additionally, the order of
starting packets is always the same, independently of the source of clock.
The corresponding driver is expected as a generator of presentation
timestamp and these models can select it as a source of sampling clock.
This commit drops reusing SYT sequence from ALSA bebob driver. The driver
always transfer packets with presentation timestamp generated by ALSA
firewire stack, without re-using the sequence of value in SYT field in
incoming packets to outgoing packets.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Make alias handler and sq_quote_argv to check the return value of strbuf
APIs.
In sq_quote_argv() calls die(), but this fix handles strbuf failure as a
special case and returns to caller, since the caller - handle_alias()
also has to check the return value of other strbuf APIs and those checks
can be merged to one if() statement.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20160510054725.6158.84597.stgit@devbox
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
When the kernel path contains a space or a colon somewhere in the path
name, the modules_install target doesn't work anymore, as the path names
are not enclosed in double quotes. It is also supposed that and O= build
will suffer from the same weakness as modules_install.
Instead of checking and improving kbuild to resist to directories
including these characters, error out early to prevent any build if the
kernel's main directory contains a space.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Michal Marek <mmarek@suse.com>
BLK_TC_NOTIFY is missed in mask_maps, so we can't print out notify or
set mask with 'notify' name.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
commit f4a1d08ce6 introduces a regression. Originally for
BLK_TN_MESSAGE, we add message in trace and return. The commit ignores
the early return and add garbage info.
Signed-off-by: Shaohua Li <shli@fb.com>
Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
KVM: s390: features and fixes for 4.7 part2
- Use hardware provided information about facility bits that do not
need any hypervisor activitiy
- Add missing documentation for KVM_CAP_S390_RI
- Some updates/fixes for handling cpu models and facilities
Make sure to deallocate fspath with vfree() in case of error in
init_ipath().
fspath is allocated with vmalloc() in init_data_container() since
commit 425d17a290 ("Btrfs: use larger limit for translation of logical to
inode").
Signed-off-by: Vincent Stehlé <vincent.stehle@intel.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Merge "ARM: dts: exynos: Devfreq for v4.7: from Krzysztof Kozłowski:
Topic branch for Device Tree changes adding new generic devfreq driver, for
v4.7:
1. Add bus nodes for Exynos3250, Exynos4x12, Exynos4210 and Exynos542x.
2. Split out common PPMU (Performance Monitoring Unit) nodes into separate
DTSI. The PPMU provides performance data for devfreq.
3. Add NoCP (Network on Chip Probe) node for Exynos542x. On this SoC, like PPMU
on older designs, provides performance data for devfreq.
4. Enable DFVS (Dynamic Voltage and Frequency Scaling) on boards:
- Exynos3250 Rinato,
- Exynos4412 Odroid-X/X2/U3 and Trats2,
- Exynos5422 Odroid XU3/XU3-Lite/XU4.
* tag 'samsung-dt-devfreq-4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
ARM: dts: exynos: Add support of Bus frequency using VDD_INT for exynos5422-odroidxu3
ARM: dts: exynos: Add bus nodes using VDD_INT for Exynos542x SoC
ARM: dts: exynos: Add NoC Probe dt node for Exynos542x SoC
ARM: dts: exynos: Add support of bus frequency for exynos4412-trats/odroidu3
ARM: dts: exynos: Expand the voltage range of buck1/3 regulator for exynos4412-odroidu3
ARM: dts: exynos: Add support of bus frequency using VDD_INT for exynos3250-rinato
ARM: dts: exynos: Add exynos4412-ppmu-common dtsi to delete duplicate PPMU nodes
ARM: dts: exynos: Add bus nodes using VDD_MIF for Exynos4210
ARM: dts: exynos: Add bus nodes using VDD_INT for Exynos4x12
ARM: dts: exynos: Add bus nodes using VDD_MIF for Exynos4x12
ARM: dts: exynos: Add bus nodes using VDD_INT for Exynos3250
ARM: dts: exynos: Add DMC bus frequency for exynos3250-rinato/monk
ARM: dts: exynos: Add DMC bus node for Exynos3250
clk: samsung: exynos542x: Add the clock id for ACLK
dt-bindings: clock: Add the clock id for ACLK clock of Exynos542x SoC
The device driver was added in v4.5 by commit dca536c433
("watchdog: add support for Sigma Designs SMP86xx/SMP87xx")
Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
It seems trigger cannot be configured too early, otherwise it does not work in
case of panel. The patch fixes also trigger flag logic, previously HW-TRIGGER
flag was cleared in case of panel - as a result panel used always software
trigger.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This allows to remove the local of_graph_get_port_by_reg(),
of_graph_get_endpoint_by_reg(), and of_get_child_by_name_reg()
functions.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Inki Dae <inki.dae@samsung.com>
This allows to remove the local of_graph_get_port_by_reg(),
of_graph_get_endpoint_by_reg(), of_get_child_by_name_reg(),
and of_graph_get_remote_port_parent() functions.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
It's an optional hook. Might be needed for frontbuffer rendering on
manual upload displays, but a simple TODO doesn't explain at all what
needs to be done or why.
Cc: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
There is no reason to be wapper functions to use DMA mapping APIs. Use
directly DMA mapping APIs and remove the wapper functions.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The regulators may not be available just because their driver's probe
function was just not executed and so the regulators not registered.
So, in this case the Exynos HDMI driver should not print logs since
a -EPROBE_DEFER is not really an error and that will just pollute
the kernel log and confuse users.
This patch prevents the following misleading messages to be printed:
[ 1.443638] [drm:hdmi_probe] *ERROR* failed to get regulators
[ 1.449326] [drm:hdmi_probe] *ERROR* hdmi_resources_init failed
Reported-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
