The scaled cputime is supposed to be derived from the normal per-thread
cputime by dividing it with the average thread density in the last interval.
The calculation of the scaling values for the average thread density is
incorrect. The current, incorrect calculation:
Ci = cycle count with i active threads
T = unscaled cputime, sT = scaled cputime
sT = T * (C1 + C2 + ... + Cn) / (1*C1 + 2*C2 + ... + n*Cn)
The calculation happens to yield the correct numbers for the simple cases
with only one Ci value not zero. But for cases with multiple Ci values not
zero it fails. E.g. on a SMT-2 system with one thread active half the time
and two threads active for the other half of the time it fails, the scaling
factor should be 3/4 but the formula gives 2/3.
The correct formula is
sT = T * (C1/1 + C2/2 + ... + Cn/n) / (C1 + C2 + ... + Cn)
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Previously, the cpum_cf PMU returned -EPERM if a counter is requested and
the counter set to which the counter belongs is not authorized. According
to the perf_event_open() system call manual, an error code of EPERM indicates
an unsupported exclude setting or CAP_SYS_ADMIN is missing.
Use ENOENT to indicate that particular counters are not available when the
counter set which contains the counter is not authorized. For generic events,
this might trigger a fall back, for example, to a software event.
Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
The uc_sigmask in the ucontext structure is an array of words to keep
the 64 signal bits (or 1024 if you ask glibc but the kernel sigset_t
only has 64 bits).
For 64 bit the sigset_t contains a single 8 byte word, but for 31 bit
there are two 4 byte words. The compat signal handler code uses a
simple copy of the 64 bit sigset_t to the 31 bit compat_sigset_t.
As s390 is a big-endian architecture this is incorrect, the two words
in the 31 bit sigset_t array need to be swapped.
Cc: <stable@vger.kernel.org>
Reported-by: Stefan Liebler <stli@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
The critical section cleanup code misses to add the offset of the
thread_struct to the task address.
Therefore, if the critical section code gets executed, it may corrupt
the task struct or restore the contents of the floating point registers
from the wrong memory location.
Fixes d0164ee20d "s390/kernel: remove save_fpu_regs() parameter and use
__LC_CURRENT instead".
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Reviewed-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
The swsusp_arch_suspend()/swsusp_arch_resume() functions currently only
save and restore the floating point registers. If the task that started
the hibernation process is using vector registers they can get lost.
To fix this just call save_fpu_regs in swsusp_arch_suspend(), the restore
will happen automatically on return to user space.
Reported-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
The nf_log_unregister() function needs to call synchronize_rcu() to make sure
that the objects are not dereferenced anymore on module removal.
Fixes: 5962815a6a ("netfilter: nf_log: use an array of loggers instead of list")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Cortex-A53 processors <= r0p4 are affected by erratum #843419 which can
lead to a memory access using an incorrect address in certain sequences
headed by an ADRP instruction.
There is a linker fix to generate veneers for ADRP instructions, but
this doesn't work for kernel modules which are built as unlinked ELF
objects.
This patch adds a new config option for the erratum which, when enabled,
builds kernel modules with the mcmodel=large flag. This uses absolute
addressing for all kernel symbols, thereby removing the use of ADRP as
a PC-relative form of addressing. The ADRP relocs are removed from the
module loader so that we fail to load any potentially affected modules.
Cc: <stable@vger.kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
When saving/restoring the VFP registers from a compat (AArch32)
signal frame, we rely on the compat registers forming a prefix of the
native register file and therefore make use of copy_{to,from}_user to
transfer between the native fpsimd_state and the compat_vfp_sigframe.
Unfortunately, this doesn't work so well in a big-endian environment.
Our fpsimd save/restore code operates directly on 128-bit quantities
(Q registers) whereas the compat_vfp_sigframe represents the registers
as an array of 64-bit (D) registers. The architecture packs the compat D
registers into the Q registers, with the least significant bytes holding
the lower register. Consequently, we need to swap the 64-bit halves when
converting between these two representations on a big-endian machine.
This patch replaces the __copy_{to,from}_user invocations in our
compat VFP signal handling code with explicit __put_user loops that
operate on 64-bit values and swap them accordingly.
Cc: <stable@vger.kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
We have a couple of CPU hotplug notifiers for resetting the CPU debug
state to a sane value when a CPU comes online.
This patch ensures that we mask out CPU_TASKS_FROZEN so that we don't
miss any online events occuring due to suspend/resume.
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
There are several actions that smp_conn_security() might make that do
not require a valid SMP context (conn->smp pointer). One of these
actions is to encrypt the link with an existing LTK. If the SMP
context wasn't initialized properly we should still allow the
independent actions to be done, i.e. the check for the context should
only be done at the last possible moment.
Reported-by: Chuck Ebbert <cebbert.lkml@gmail.com>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org # 4.0+
ioremap_cache() is currently not available on some architectures.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
The commit [b67893206fc0: leds:lp55xx: fix firmware loading error]
tries to address the firmware file handling with user helper, but it
sets a wrong Kconfig CONFIG_FW_LOADER_USER_HELPER_FALLBACK. Since the
wrong option was enabled, the system got a regression -- it suffers
from the unexpected long delays for non-present firmware files.
This patch corrects the Kconfig dependency to the right one,
CONFIG_FW_LOADER_USER_HELPER. This doesn't change the fallback
behavior but only enables UMH when needed.
Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=944661
Fixes: b67893206f ('leds:lp55xx: fix firmware loading error')
Cc: <stable@vger.kernel.org> # v4.2+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.
Signed-off-by: Luis de Bethencourt <luis@debethencourt.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.
Signed-off-by: Luis de Bethencourt <luis@debethencourt.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.
Signed-off-by: Luis de Bethencourt <luis@debethencourt.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.
Signed-off-by: Luis de Bethencourt <luis@debethencourt.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.
Signed-off-by: Luis de Bethencourt <luis@debethencourt.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.
Signed-off-by: Luis de Bethencourt <luis@debethencourt.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
First series of fixes for v4.3-rc cycle. The major points are
a fix to a regression which would let gadget driver disable
an endpoint that's already disabled and a fix to MUSB to make
sure IRQs are masked when we're going to suspend and unmasked
on resume.
Signed-off-by: Felipe Balbi <balbi@ti.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJV+Zw6AAoJEIaOsuA1yqREdFgP/i9xNC80evxVuEJuOLvojYU0
UWosc2/9PXLfQFfaK/RaXdY/FyHeDdOgXHkdSHDy86GGAYNY1VPhZ8qjcoxKWDZc
ElgsRLEeCY2GwZrHewS9wnzH0lPPWEta14hXJngdOvDFYz4CyQqvEuNFUzKG1plT
4eRN0LBuqOZTe4Mp+iYsK97DinFIi4bAVvEqApYTim8pF/s6TUMpnv8N4gJaW01M
kwR9svduMl6vJbO6NXedpj9L+tYqr+cMhByexX543XRw5lWfoLyad8GwcH1CjEay
gMH/cEq36baLRRdr3EvfcSI+pSlispk/VOdw+YXWtWSNStu8CMeElojAAvr5PaxO
9WJ/Vf8c+NExjiCEOsCUrPTC7QCAubxXmikDC2UxOpcTMibBHODglQIJ/sj14LK6
9j45T3jsu49AmTF2yKuV8CiNLT7uE8kFTirYk1AqDIyCFhNcQiy4ZQGDvd8E+uFv
WHKA0zgJvIeeOjPNZqlifuCvaxiY1D7xCkU0O/J7JzLc6iBU3nc6mYsiG2YM3Pdu
YovgNJMhqD/rGdFQN3d6PgPBC4JxcYluLpxxB7PWAEgqwL8eIHH85+BcmH1WYFhX
74vVLutYJ+c6RzJPWJRu5tP/BcLlIbUD1ATJlbfyeSbiERqH0FCtxUgE0GuyZvcp
YR9da/I3TxDzVQY+zlmS
=TQho
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-v4.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
Felipe writes:
usb: fixes for v4.3-rc2
First series of fixes for v4.3-rc cycle. The major points are
a fix to a regression which would let gadget driver disable
an endpoint that's already disabled and a fix to MUSB to make
sure IRQs are masked when we're going to suspend and unmasked
on resume.
Signed-off-by: Felipe Balbi <balbi@ti.com>
memset() uses instruction dcbz to speed up clearing by not wasting time
loading cache line with data that will be overwritten.
Some platform like mpc52xx do no have cache active at startup and
can therefore not use memset(). Allthough no part of the code
explicitly uses memset(), GCC may make calls to it.
This patch modifies memset() such that at startup, memset()
unconditionally skip the optimised bloc that uses dcbz instruction.
Once the initial MMU is set up, in machine_init() we patch memset()
by replacing this inconditional jump by a NOP
Tested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
memcpy() uses instruction dcbz to speed up copy by not wasting time
loading cache line with data that will be overwritten.
Some platform like mpc52xx do no have cache active at startup and
can therefore not use memcpy(). Allthough no part of the code
explicitly uses memcpy(), GCC makes calls to it.
This patch modifies memcpy() such that at startup, memcpy()
unconditionally jumps to generic_memcpy() which doesn't use
the dcbz instruction.
Once the initial MMU is set up, in machine_init() we patch memcpy()
by replacing this inconditional jump by a NOP
Reported-by: Michal Sojka <sojkam1@fel.cvut.cz>
Tested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
The VBUS line of USB2 is connected to VBUS detect logic on
the PMIC. Use the palmas-usb driver to report VBUS events
to the USB driver.
As the palmas-usb driver supports GPIO based ID reporting
provide the GPIO for ID pin as well.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This enables tca6424a GPIO expander driver that in turn enables
TPD12S015 HDMI ESD protection and level shifter on OMAP5 uevm.
In other words, it makes HDMI work on OMAP5 uevm.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The i2c5 pinctrl offsets are wrong. If the bootloader doesn't set the
pins up, communication with tca6424a doesn't work (controller timeouts)
and it is not possible to enable HDMI.
Fixes: 9be495c426 ("ARM: dts: omap5-evm: Add I2c pinctrl data")
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Add omap2_clk_enable_autoidle_all to am43xx_init_late otherwise the call
to omap2_clk_disable_autoidle_all in am43xx_init_early may cause some
clocks to always stay active and prevent low power mode transitions.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Originally, all the SoC PHY rails were supplied by LDO3. However, as a
result of characterization, it was determined that this posed a risk in
extreme load conditions. Hence the PHY rails are split between two
different LDOs. Update the related node as a result
LDO3/VDDA_1V8_PHYA supplies vdda_usb1, vdda_usb2, vdda_sata, vdda_usb3
LDO4/VDDA_1V8_PHYB supplies vdda_pcie1, vdda_pcie0, vdda_hdmi, vdda_pcie
NOTE: We break compatibility with pre-production boards with this change
since, the PMIC LDO4 is disabled at OTP level.
The new configuration is the plan of record and all pre-production
boards are supposed to be replaced with the latest boards matching the
mentioned configuration.
Some very few 10 something boards have been created and
stopped production till the latest modifications were done (PMIC USB
interrupt, LDO4 etc) - and all of those boards are now getting
scrapped.. If there are any (as per tracking information, there should
not be any), TI should be contacted to have them replaced.
Signed-off-by: Nishanth Menon <nm@ti.com>
[tony@atomide.com: updated commit about these being TI internal protos]
Signed-off-by: Tony Lindgren <tony@atomide.com>
In (23a4e40 arm: kgdb: Handle read-only text / modules) we moved to
using patch_text() to set breakpoints so that we could handle the case
when we had CONFIG_DEBUG_RODATA. That patch used patch_text().
Unfortunately, patch_text() assumes that we're not in atomic context
when it runs since it needs to grab a mutex and also wait for other
CPUs to stop (which it does with a completion).
This would result in a stack crawl if you had
CONFIG_DEBUG_ATOMIC_SLEEP and tried to set a breakpoint in kgdb. The
crawl looked something like:
BUG: scheduling while atomic: swapper/0/0/0x00010007
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc7-00133-geb63b34 #1073
Hardware name: Rockchip (Device Tree)
(unwind_backtrace) from [<c00133d4>] (show_stack+0x20/0x24)
(show_stack) from [<c05400e8>] (dump_stack+0x84/0xb8)
(dump_stack) from [<c004913c>] (__schedule_bug+0x54/0x6c)
(__schedule_bug) from [<c054065c>] (__schedule+0x80/0x668)
(__schedule) from [<c0540cfc>] (schedule+0xb8/0xd4)
(schedule) from [<c0543a3c>] (schedule_timeout+0x2c/0x234)
(schedule_timeout) from [<c05417c0>] (wait_for_common+0xf4/0x188)
(wait_for_common) from [<c0541874>] (wait_for_completion+0x20/0x24)
(wait_for_completion) from [<c00a0104>] (__stop_cpus+0x58/0x70)
(__stop_cpus) from [<c00a0580>] (stop_cpus+0x3c/0x54)
(stop_cpus) from [<c00a06c4>] (__stop_machine+0xcc/0xe8)
(__stop_machine) from [<c00a0714>] (stop_machine+0x34/0x44)
(stop_machine) from [<c00173e8>] (patch_text+0x28/0x34)
(patch_text) from [<c001733c>] (kgdb_arch_set_breakpoint+0x40/0x4c)
(kgdb_arch_set_breakpoint) from [<c00a0d68>] (kgdb_validate_break_address+0x2c/0x60)
(kgdb_validate_break_address) from [<c00a0e90>] (dbg_set_sw_break+0x1c/0xdc)
(dbg_set_sw_break) from [<c00a2e88>] (gdb_serial_stub+0x9c4/0xba4)
(gdb_serial_stub) from [<c00a11cc>] (kgdb_cpu_enter+0x1f8/0x60c)
(kgdb_cpu_enter) from [<c00a18cc>] (kgdb_handle_exception+0x19c/0x1d0)
(kgdb_handle_exception) from [<c0016f7c>] (kgdb_compiled_brk_fn+0x30/0x3c)
(kgdb_compiled_brk_fn) from [<c00091a4>] (do_undefinstr+0x1a4/0x20c)
(do_undefinstr) from [<c001400c>] (__und_svc_finish+0x0/0x34)
It turns out that when we're in kgdb all the CPUs are stopped anyway
so there's no reason we should be calling patch_text(). We can
instead directly call __patch_text() which assumes that CPUs have
already been stopped.
Fixes: 23a4e4050b ("arm: kgdb: Handle read-only text / modules")
Reported-by: Aapo Vienamo <avienamo@nvidia.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Commit 96231b2686b5: ("ARM: 8419/1: dma-mapping: harmonize definition
of DMA_ERROR_CODE") changed the definition of DMA_ERROR_CODE to use
dma_addr_t, which makes the compiler barf on assigning this to an
"int" variable on ARM with LPAE enabled:
*************
In file included from /src/linux/include/linux/dma-mapping.h:86:0,
from /src/linux/arch/arm/mm/dma-mapping.c:21:
/src/linux/arch/arm/mm/dma-mapping.c: In function '__iommu_create_mapping':
/src/linux/arch/arm/include/asm/dma-mapping.h:16:24: warning:
overflow in implicit constant conversion [-Woverflow]
#define DMA_ERROR_CODE (~(dma_addr_t)0x0)
^
/src/linux/arch/arm/mm/dma-mapping.c:1252:15: note: in expansion of
macro DMA_ERROR_CODE'
int i, ret = DMA_ERROR_CODE;
^
*************
Remove the actually unneeded initialization of "ret" in
__iommu_create_mapping() and move the variable declaration inside the
for-loop to make the scope of this variable more clear.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Remove the #if statement which caused trouble for kernels that support
both ARMv6 and ARMv7. Older architectures do not implement these bits,
so it should be safe to always clear them.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
If a mux clock is initialised (by hardware or firmware) with an
invalid parent, its ->get_parent() can return an out of range
index. For example, the generic mux clock attempts to return
-EINVAL, which due to the u8 return type ends up a rather large
number. Using this index with the parent_names[] array results
in an invalid pointer and (usually) a crash in the following
strcmp().
This patch adds a check for the parent index being in range,
ignoring clocks reporting invalid values.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Tested-by: Rhyland Klein <rklein@nvidia.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
The OPP list needs to be protected against concurrent accesses. Using
simple RCU read locks does the trick and gets rid of the following
lockdep warning:
===============================
[ INFO: suspicious RCU usage. ]
4.2.0-next-20150908 #1 Not tainted
-------------------------------
drivers/base/power/opp.c:460 Missing rcu_read_lock() or dev_opp_list_lock protection!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
4 locks held by kworker/u8:0/6:
#0: ("%s""deferwq"){++++.+}, at: [<c0040d8c>] process_one_work+0x118/0x4bc
#1: (deferred_probe_work){+.+.+.}, at: [<c0040d8c>] process_one_work+0x118/0x4bc
#2: (&dev->mutex){......}, at: [<c03b8194>] __device_attach+0x20/0x118
#3: (prepare_lock){+.+...}, at: [<c054bc08>] clk_prepare_lock+0x10/0xf8
stack backtrace:
CPU: 2 PID: 6 Comm: kworker/u8:0 Not tainted 4.2.0-next-20150908 #1
Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
Workqueue: deferwq deferred_probe_work_func
[<c001802c>] (unwind_backtrace) from [<c00135a4>] (show_stack+0x10/0x14)
[<c00135a4>] (show_stack) from [<c02a8418>] (dump_stack+0x94/0xd4)
[<c02a8418>] (dump_stack) from [<c03c6f6c>] (dev_pm_opp_find_freq_ceil+0x108/0x114)
[<c03c6f6c>] (dev_pm_opp_find_freq_ceil) from [<c0551a3c>] (dfll_calculate_rate_request+0xb8/0x170)
[<c0551a3c>] (dfll_calculate_rate_request) from [<c0551b10>] (dfll_clk_round_rate+0x1c/0x2c)
[<c0551b10>] (dfll_clk_round_rate) from [<c054de2c>] (clk_calc_new_rates+0x1b8/0x228)
[<c054de2c>] (clk_calc_new_rates) from [<c054e44c>] (clk_core_set_rate_nolock+0x44/0xac)
[<c054e44c>] (clk_core_set_rate_nolock) from [<c054e4d8>] (clk_set_rate+0x24/0x34)
[<c054e4d8>] (clk_set_rate) from [<c0512460>] (tegra124_cpufreq_probe+0x120/0x230)
[<c0512460>] (tegra124_cpufreq_probe) from [<c03b9cbc>] (platform_drv_probe+0x44/0xac)
[<c03b9cbc>] (platform_drv_probe) from [<c03b84c8>] (driver_probe_device+0x218/0x304)
[<c03b84c8>] (driver_probe_device) from [<c03b69b0>] (bus_for_each_drv+0x60/0x94)
[<c03b69b0>] (bus_for_each_drv) from [<c03b8228>] (__device_attach+0xb4/0x118)
ata1: SATA link down (SStatus 0 SControl 300)
[<c03b8228>] (__device_attach) from [<c03b77c8>] (bus_probe_device+0x88/0x90)
[<c03b77c8>] (bus_probe_device) from [<c03b7be8>] (deferred_probe_work_func+0x58/0x8c)
[<c03b7be8>] (deferred_probe_work_func) from [<c0040dfc>] (process_one_work+0x188/0x4bc)
[<c0040dfc>] (process_one_work) from [<c004117c>] (worker_thread+0x4c/0x4f4)
[<c004117c>] (worker_thread) from [<c0047230>] (kthread+0xe4/0xf8)
[<c0047230>] (kthread) from [<c000f7d0>] (ret_from_fork+0x14/0x24)
Signed-off-by: Thierry Reding <treding@nvidia.com>
Fixes: c4fe70ada4 ("clk: tegra: Add closed loop support for the DFLL")
[vince.h@nvidia.com: Unlock rcu on error path]
Signed-off-by: Vince Hsu <vince.h@nvidia.com>
[sboyd@codeaurora.org: Dropped second hunk that nested the rcu
read lock unnecessarily]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Add missing zero to value. This will be needed when range checking
is implemented.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Acked-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The previous fix of pxa library support, which was introduced to fix the
library dependency, broke the previous SoC behavior, where a machine
code binding pxa2xx-ac97 with a coded relied on :
- sound/soc/pxa/pxa2xx-ac97.c
- sound/soc/codecs/XXX.c
For example, the mioa701_wm9713.c machine code is currently broken. The
"select ARM" statement wrongly selects the soc/arm/pxa2xx-ac97 for
compilation, as per an unfortunate fate SND_PXA2XX_AC97 is both declared
in sound/arm/Kconfig and sound/soc/pxa/Kconfig.
Fix this by ensuring that SND_PXA2XX_SOC correctly triggers the correct
pxa2xx-ac97 compilation.
Fixes: 846172dfe3 ("ASoC: fix SND_PXA2XX_LIB Kconfig warning")
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit adcbcfea15 ("spi: mediatek: fix spi clock usage error")
added a new sel_clk but introduced bugs in the error paths since
the wrong struct clk pointers are passed to PTR_ERR().
Fixes: adcbcfea15 ("spi: mediatek: fix spi clock usage error")
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix the following 'make htmldocs' warnings:
.//include/linux/spi/spi.h:71: warning: No description found for parameter 'lock'
.//include/linux/spi/spi.h:71: warning: Excess struct/union/enum/typedef member 'clock' description in 'spi_statistics'
Signed-off-by: Geliang Tang <geliangtang@163.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
irq_data_get_chip() function does not exist, call irq_desc_get_chip()
instead.
Fixes: 9ec97561aa ("ARM/pxa: Prepare balloon3_irq_handler for irq argument removal")
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Until b26e5fdac4 ("arm/arm64: KVM: introduce per-VM ops"),
kvm_vgic_map_resources() used to include a check on irqchip_in_kernel(),
and vgic_v2_map_resources() still has it.
But now vm_ops are not initialized until we call kvm_vgic_create().
Therefore kvm_vgic_map_resources() can being called without a VGIC,
and we die because vm_ops.map_resources is NULL.
Fixing this restores QEMU's kernel-irqchip=off option to a working state,
allowing to use GIC emulation in userspace.
Fixes: b26e5fdac4 ("arm/arm64: KVM: introduce per-VM ops")
Cc: stable@vger.kernel.org
Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
[maz: reworked commit message]
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
- Fix long time regression on beagle for tfp410 pin muxing
- Fix dm814x control base address typo and related Ethernet
phy configuration
- Fix igepv2 Ethernet pinmuxing as only some boards have it
- Fix pbias regulator compatible values as a pending regulator
fix needs those for MMC1 to work properly
- Fix beagle-x15 MMC1 regulator and make pcf857x built-in
- Fix omap5 and dra7 Kconfig options when built as the only
SoCs selected
- Fix PM errata for omap5 and dra7 as they too need it
- Fix phycore mpu voltage
Also included are a few cosmetic fixes:
- Remove unused of_irq macros
- Fix dra7 ethernet name
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJV9zECAAoJEBvUPslcq6VzROgP/1f1wd0NFGnuA8JIcFayYAbu
SprUbKfG7RKwL2Qkpg1qs34TuxEwZFd6HoAu19rGeRimbQg04TdzZhk/xMjmLjpC
yi7o51kMl09oyiZ8ITkZYSUDsD6FO4R9GoE9SRyorSzKxnJnO5UhmPdTsKqADQAe
Sd6YeVvKXGJIp3umNXRoEUPhUDjewJr0/QwLnkNutWZh99cieWYM0ROR0zJ6QpYD
MvThfi4/puVEqvwkOXfSGIaj81TQgW1wpaLOBeNV0M05yWI5SZIoLzyVdeF5ln+n
E2qUji96n9WbSuKQIHVeQk5Ld6DyPuh6nktSphytNW0ZT4CU1wQdzySHHEjDu3x9
grMWNHe/LL5C9MJnPD0oVtlu+rQ7ABENi5//RyNvj/TAKmTJrHjKusO4LRR3fpQY
3BWogXLXYZ6eyaUOH0arILkzQaFudaVMWlVoollmHGGyLVuwqXqqktfoHfLYm4Fs
A6DtvANOo95L1ltX57SJGfA2/GiUHLtom3M6ATAHTN9/LapFscRaXUArNO7Hx9an
vqo2MIIGDLakSINohelbF0tssuUqEfhyybATMJRiaJMWY1zND43LhPEtsOZxZSny
7+sKtNG+jF/CQBfvMVZw69IcVU4S76fJkTitb19N1CNtHLyU2gi5mgTI1YFkBah1
15JPwlq2rj1Q6B3Vu2qw
=2Q1v
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v4.3/fixes-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
Merge "omap fixes against v4.3-rc1" from Tony Lindgren:
Fixes for omaps against v4.3-rc1:
- Fix long time regression on beagle for tfp410 pin muxing
- Fix dm814x control base address typo and related Ethernet
phy configuration
- Fix igepv2 Ethernet pinmuxing as only some boards have it
- Fix pbias regulator compatible values as a pending regulator
fix needs those for MMC1 to work properly
- Fix beagle-x15 MMC1 regulator and make pcf857x built-in
- Fix omap5 and dra7 Kconfig options when built as the only
SoCs selected
- Fix PM errata for omap5 and dra7 as they too need it
- Fix phycore mpu voltage
Also included are a few cosmetic fixes:
- Remove unused of_irq macros
- Fix dra7 ethernet name
* tag 'omap-for-v4.3/fixes-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: dts: Fixup model name for HP t410 dts
ARM: dts: DRA7: fix a typo in ethernet
ARM: omap2plus_defconfig: make PCF857x built-in
ARM: dts: Use ti,pbias compatible string for pbias
ARM: OMAP5: Cleanup options for SoC only build
ARM: DRA7: Select missing options for SoC only build
ARM: OMAP2+: board-generic: Remove stale of_irq macros
ARM: OMAP4+: PM: erratum is used by OMAP5 and DRA7 as well
ARM: dts: omap3-igep: Move eth IRQ pinmux to IGEPv2 common dtsi
ARM: dts: am57xx-beagle-x15: Add wakeup irq for mcp79410
ARM: dts: am335x-phycore-som: Fix mpu voltage
ARM: dts: am57xx-beagle-x15: Fix regulator populated in MMC1 dt node
ARM: dts: Fix dm814x control base to properly initialize Ethernet PHY
ARM: dts: omap3-beagle: make i2c3, ddc and tfp410 gpio work again
- Move ehca driver to staging/rdma and schedule for deletion
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJV9xxNAAoJELgmozMOVy/dI+QP/R0afI1zc7pJe1D2RmrZWnAH
HDWSNYJ8eVk25ptnaOes9kV6yuOV1nGiyCIGqUXk8Q7rVYbIIz0nK81S+gPLMpTU
/la28bmUz7szvEtY+gFHZCuQvCiwjM+N7t39aehIMCc/vYnIdrOXuYMhB8kd6flL
2mpnUFmfqMZLGh4RY1PQB9cNwVW9yYOVnG+1Z/M26wWl3NIDe4jiNoqV/jFvEf2v
FyzjcYfjexVA47XOsfGy512Vlb+8DTtFeCz/TRl9e8tYCSHOmTcXv7jLywRoA1zn
NNwJnXhliM9/EDqtbJMymYDAm9vzcfvXPCx1OOisVWxJxg9IF3p2/uPLeIKUSXZl
15mfOzoTuNXlunHDQYbzC4+P2zs+uU2k6ivpd7HZgyiBkUXzftYh/6gIJcJOreU6
1ndt2fK5hcG/Was+v6kkYaw0x6ZpawyLqHMs32V1xVcbmM5P1OFFOQFx1KDYhHH8
WmOlcd/XmIjNY5o3ySQHSKjO6Ar0IfNyzpU3jUzg2AFbZv8m2BgYEhQOnrggxBtM
deFbDlxMnIrsIJtsHBmr5Y/nsgIYpkxLK4xUod76yZSRuyjLCH/2C0otubS1w1vH
4unU9zJXboBi7naPE5/fdIPMhwZu1X47xUyrwGksz3pHyiRpnhq55t+AWpsHCrg+
+XYexztBX/cPReacpWJR
=4XzR
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma
Pull rdma driver move from Doug Ledford:
"This is a move only, no functional changes.
I tried to get it in prior to the rc1 release, but we were waiting on
IBM to get back to us that they were OK with the deprecation and
eventual removal of this driver. That OK didn't materialize until
last week, so integration and testing time pushed us beyond the rc1
release.
Summary:
- Move ehca driver to staging/rdma and schedule for deletion"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma:
IB/ehca: Deprecate driver, move to staging, schedule deletion
This reverts commit d59cfc09c3.
d59cfc09c3 ("sched, cgroup: replace signal_struct->group_rwsem with
a global percpu_rwsem") and b5ba75b5fc ("cgroup: simplify
threadgroup locking") changed how cgroup synchronizes against task
fork and exits so that it uses global percpu_rwsem instead of
per-process rwsem; unfortunately, the write [un]lock paths of
percpu_rwsem always involve synchronize_rcu_expedited() which turned
out to be too expensive.
Improvements for percpu_rwsem are scheduled to be merged in the coming
v4.4-rc1 merge window which alleviates this issue. For now, revert
the two commits to restore per-process rwsem. They will be re-applied
for the v4.4-rc1 merge window.
Signed-off-by: Tejun Heo <tj@kernel.org>
Link: http://lkml.kernel.org/g/55F8097A.7000206@de.ibm.com
Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: stable@vger.kernel.org # v4.2+
This reverts commit b5ba75b5fc.
d59cfc09c3 ("sched, cgroup: replace signal_struct->group_rwsem with
a global percpu_rwsem") and b5ba75b5fc ("cgroup: simplify
threadgroup locking") changed how cgroup synchronizes against task
fork and exits so that it uses global percpu_rwsem instead of
per-process rwsem; unfortunately, the write [un]lock paths of
percpu_rwsem always involve synchronize_rcu_expedited() which turned
out to be too expensive.
Improvements for percpu_rwsem are scheduled to be merged in the coming
v4.4-rc1 merge window which alleviates this issue. For now, revert
the two commits to restore per-process rwsem. They will be re-applied
for the v4.4-rc1 merge window.
Signed-off-by: Tejun Heo <tj@kernel.org>
Link: http://lkml.kernel.org/g/55F8097A.7000206@de.ibm.com
Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: stable@vger.kernel.org # v4.2+
Add support for NCT6793D, and fix swapped registers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJV+X7kAAoJEMsfJm/On5mBhPAP/2aWMuRrLl2bx7EUgqB84PAV
i3ynORuSBX1yfVPYxaU1W7OsoXlD4+62gMLgvmVO2w+yjLnveowI9cCQYL3wmcg3
ASG5NdpbwKGZwYc0q7ofi67zdYYYEdR9OtR1Raw8DROV7cZiuhhnA6vGYEI9m5Dz
TbSAolTcaBino0cNGVRiD/ohktqvJSxnnxI73KRx0bgAOS3oiCRCdn760DaiXpEn
FX99JtB9arBFX5wTx2KHQpGvFiqtIGUk+2ghyiKODjmfI2Hy+Jgh/c4VMcb9+p8K
VP/JYXh1k7fBBOZlmn4qXJh8Ls36k0PwKefa9KbyyflICNYLjv7bqv3gt9hCQcW/
BoXR58mH6wfrjhMdnZv3gNEDj1rN8FkMtAEYHNyykVnHOLbPDM0D1mDesKdQeO8K
mvMGNk0FU4j6JNS7GmhnoZUE39qBjG9uiWqElt3aiVMP+t9eV4If0BSxQV0xe+un
b1CwbcpEtvdXQn4DW3Qn0pu+aI/WpBTU1QoUH+3Z2XmPaaQGvZx+4Qm4XhlOgFkW
WFi3Cc+Uets3IbhsfCdGwNttGjufHb28dAX3IfkCdpEOd62HH03jsMobKT2PEKx1
01CzyBwLUhx3EkqZCWJvlM8OVbqG1991JS5e0qJ2tMJgND242ZiL71TtXyahMF/H
mmYb9Wrg9hgvzBwolKrg
=/U4E
-----END PGP SIGNATURE-----
Merge tag 'hwmon-for-linus-v4.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
Pull hwmon fixes from Guenter Roeck:
"Two patches for the nct6775 driver: add support for NCT6793D, and fix
swapped registers"
* tag 'hwmon-for-linus-v4.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
hwmon: (nct6775) Add support for NCT6793D
hwmon: (nct6775) Swap STEP_UP_TIME and STEP_DOWN_TIME registers for most chips
- Some IS_ERR() fixes from Julia Lawall. I always wanted the compiler
to catch these but error pointers by nailing them as an err pointer
intrinsic type or something seem to be a "no can do". In any
case, cocinelle is obviously up to the task, better than bugs
staying around.
- Better error handling for NULL GPIO chips.
- Fix a compile error from the big irq desc refactoring. I'm
surprised the fallout wasn't bigger than this.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJV+VRDAAoJEEEQszewGV1z7UQP+wZi0VTV3VY04sbGxFe9NTCl
BSXcFYoxq/6SMRkgewa47MIqEejO0q8Qq+2wE1HhUy4xiCSg5XLxCJGePqUGsglf
0GjUbTinXuc+HqEdR56xqz+H8RAjC5bqlUFOhXNPhpmAJlLvg6WL4t/08Dcd2N/9
RuoAlbPqzO8ingAvoj4r8cwF7/4pRojOvh/aFQ5jZ4aVriL04Uqnzdnf4OmplNIj
gzEMICTIg6hQo0iWrKnn97DSHGR4UFKn7FQxF6g48tOIzE4hiWgfyXdpY6emG0Zi
eeEH6y/kAk3V3kmNqLe83N8TLBiHvKoj33s/ZtFuLHoakeMcQR3B3FUodQWAEs8A
6bzB8bninXEU8h8eyOhly/0DIOM6rGTEyNgPcJI0F5CSfcB5uFdl5s+X4xEEiwKo
Bsx1sfLKKI7p7lWXbML+7B+3JcgLr4E0yT6QsC9yA2AyHIgtZIBfp1hc82U9Qfgf
lheT09XGGS+8uuECQuG3woI/qokZdHlnIGsY28sqEJVrSKyXoYSFZ03YZi2DEKsj
2qPJfpfEE6x6gMUsfh+u1oJlfYrJfSU+X4uBFJ9estLOX7J9y/nygULZutQFImZ1
hUBhFDnUiKe33oe4VuLplDt/KkQ1JGC32mgYsSVGTLzUS2/vyeTlYsLXxsohLgv6
0fec5ExVS9/JWJHwFwOf
=xpIg
-----END PGP SIGNATURE-----
Merge tag 'pinctrl-v4.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
"This is a first set of pin control fixes for the v4.3 series. Nothing
special to say, business as usual.
- Some IS_ERR() fixes from Julia Lawall. I always wanted the
compiler to catch these but error pointers by nailing them as an
err pointer intrinsic type or something seem to be a "no can do".
In any case, cocinelle is obviously up to the task, better than
bugs staying around.
- Better error handling for NULL GPIO chips.
- Fix a compile error from the big irq desc refactoring. I'm
surprised the fallout wasn't bigger than this"
* tag 'pinctrl-v4.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: samsung: s3c24xx: fix syntax error
pinctrl: core: Warn about NULL gpio_chip in pinctrl_ready_for_gpio_range()
pinctrl: join lines that can be a single line within 80 columns
pinctrl: digicolor: convert null test to IS_ERR test
pinctrl: qcom: ssbi: convert null test to IS_ERR test
The offending commit accidentally replaces an atomic_clear with an
atomic_or instead of an atomic_andnot in kvm_s390_vcpu_request_handled.
The symptom is that kvm guests on s390 hang on startup.
This patch simply replaces the incorrect atomic_or with atomic_andnot
Fixes: 805de8f43c (atomic: Replace atomic_{set,clear}_mask() usage)
Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
- Return value checks and thus nicer errorpath for two drivers.
- Make GPIO_RCAR arch neutral.
- Propagate errors from GPIO chip ->get() vtable call. It turned
out these can actually fail sometimes, especially on slowpath
controllers doing I2C traffic and similar.
- Update documentation to be in sync with the massive changes in
the v4.3 merge window, phew.
- Handle deferred probe properly in the OMAP driver.
- Get rid of surplus MODULE_ALIAS() from sx150x.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJV+RcuAAoJEEEQszewGV1zMqwQALnqXAvtJGw7CaKOiShm3ywH
JPm4jMh7iiUFI8H+k6TscwxRz7bPKrezsCZleUxz/BOu/sAA9bVarYU3Fcl5HwZD
0qVszWCQ3E44qMh708F/B2kuQWdMl3u0aY9AGcNm0e4uDZ+hxXQ/jw+B1N/W0KFL
vkCCCG/uE5eoRsOkOlEtm0UI+DjHRSpzEkgZ/1HmFfBtZaQuvHOMc5ouzT72hMQn
YOk9lKPqjivGzDZYiISfmb62uuDQ8YnwsWZvP5SEbNdEgSlVes5Njd59pnxJgjYg
tSQO37Sm0kNafbIao71DHrTBWHRxvsNeLuaDRnfNj95W8QtcYjvWrqCd3kBIeAt5
ZgUlm6mKEeZuz2PW+biT4DC7hPpV0LXCwTjjHtJ6S5w7JuM3+2HpHDItbYfs5SiL
40VlXKuLPOlxt6f179+4YTRwtaotQ6Bw0Rcflh5Sa4qq7LmZFghwSwtCDsNsWhWq
qnFRoqbDmcxXBbnOuTvhM4DVCv7bvyQpos3EoFVANGg/T2zJ+8TEfi1ClHd5CbFO
WHbgVaYVwLsfGgYX5Hq5aF/dhl4NSSDpikUhcDCvX62HoeImGFcWrybzIjk+9QND
dCFS2ldd2znVZsCszCVAvtKmv0+TACb2iUK8Anhte8aYc1PLnhYT95BqUSB9QiyI
Df6Pj5FQiLEyAnxVIrEh
=72G1
-----END PGP SIGNATURE-----
Merge tag 'gpio-v4.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO fixes from Linus Walleij:
"This is the first round of GPIO fixes for v4.3. Quite a lot of
patches, but the influx of new stuff in the merge window was equally
big, so I'm not surprised.
- Return value checks and thus nicer errorpath for two drivers.
- Make GPIO_RCAR arch neutral.
- Propagate errors from GPIO chip ->get() vtable call. It turned out
these can actually fail sometimes, especially on slowpath
controllers doing I2C traffic and similar.
- Update documentation to be in sync with the massive changes in the
v4.3 merge window, phew.
- Handle deferred probe properly in the OMAP driver.
- Get rid of surplus MODULE_ALIAS() from sx150x"
* tag 'gpio-v4.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
gpio: omap: Fix GPIO numbering for deferred probe
Documentation: gpio: Explain that <function>-gpio is also supported
gpio: omap: Fix gpiochip_add() handling for deferred probe
gpio: sx150x: Remove unnecessary MODULE_ALIAS()
Documentation: gpio: board: describe the con_id parameter
Documentation: gpio: board: add flags parameter to gpiod_get*() functions
gpio: Propagate errors from chip->get()
gpio: rcar: GPIO_RCAR doesn't relate to ARM
gpio: mxs: need to check return value of irq_alloc_generic_chip
gpio: mxc: need to check return value of irq_alloc_generic_chip
Now that all users of set_irq_flags and custom flags are converted to
genirq functions, the ARM specific set_irq_flags can be removed.
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Now that all users of set_irq_flags and custom flags are converted to
genirq functions, the ARM specific set_irq_flags can be removed.
Signed-off-by: Rob Herring <robh@kernel.org>
Tested-by: Kevin Hilman <khilman@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Martin Schwidefsky