20 Jan, 2017
17 commits
-
commit f931ab479dd24cf7a2c6e2df19778406892591fb upstream.
Both arch_add_memory() and arch_remove_memory() expect a single threaded
context.For example, arch/x86/mm/init_64.c::kernel_physical_mapping_init() does
not hold any locks over this check and branch:if (pgd_val(*pgd)) {
pud = (pud_t *)pgd_page_vaddr(*pgd);
paddr_last = phys_pud_init(pud, __pa(vaddr),
__pa(vaddr_end),
page_size_mask);
continue;
}pud = alloc_low_page();
paddr_last = phys_pud_init(pud, __pa(vaddr), __pa(vaddr_end),
page_size_mask);The result is that two threads calling devm_memremap_pages()
simultaneously can end up colliding on pgd initialization. This leads
to crash signatures like the following where the loser of the race
initializes the wrong pgd entry:BUG: unable to handle kernel paging request at ffff888ebfff0000
IP: memcpy_erms+0x6/0x10
PGD 2f8e8fc067 PUD 0 /*
Cc: Christoph Hellwig
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 20f664aabeb88d582b623a625f83b0454fa34f07 upstream.
Andreas reported [1] made a test in jemalloc hang in THP mode in arm64:
http://lkml.kernel.org/r/mvmmvfy37g1.fsf@hawking.suse.de
The problem is currently page fault handler doesn't supports dirty bit
emulation of pmd for non-HW dirty-bit architecture so that application
stucks until VM marked the pmd dirty.How the emulation work depends on the architecture. In case of arm64,
when it set up pte firstly, it sets pte PTE_RDONLY to get a chance to
mark the pte dirty via triggering page fault when store access happens.
Once the page fault occurs, VM marks the pmd dirty and arch code for
setting pmd will clear PTE_RDONLY for application to proceed.IOW, if VM doesn't mark the pmd dirty, application hangs forever by
repeated fault(i.e., store op but the pmd is PTE_RDONLY).This patch enables pmd dirty-bit emulation for those architectures.
[1] b8d3c4c3009d, mm/huge_memory.c: don't split THP page when MADV_FREE syscall is called
Fixes: b8d3c4c3009d ("mm/huge_memory.c: don't split THP page when MADV_FREE syscall is called")
Link: http://lkml.kernel.org/r/1482506098-6149-1-git-send-email-minchan@kernel.org
Signed-off-by: Minchan Kim
Reported-by: Andreas Schwab
Tested-by: Andreas Schwab
Acked-by: Kirill A. Shutemov
Acked-by: Michal Hocko
Cc: Jason Evans
Cc: Will Deacon
Cc: Catalin Marinas
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 965d004af54088d138f806d04d803fb60d441986 upstream.
Currently in DAX if we have three read faults on the same hole address we
can end up with the following:Thread 0 Thread 1 Thread 2
-------- -------- --------
dax_iomap_fault
grab_mapping_entry
lock_slot
dax_iomap_fault
grab_mapping_entry
get_unlocked_mapping_entry
dax_iomap_fault
grab_mapping_entry
get_unlocked_mapping_entry
dax_load_hole
find_or_create_page
...
page_cache_tree_insert
dax_wake_mapping_entry_waiter
__radix_tree_replace
get_page
lock_page
...
put_locked_mapping_entry
unlock_page
put_pageThe crux of the problem is that once we insert a 4k zero page, all
locking from then on is done in terms of that 4k zero page and any
additional threads sleeping on the empty DAX entry will never be woken.Fix this by waking all sleepers when we replace the DAX radix tree entry
with a 4k zero page. This will allow all sleeping threads to
successfully transition from locking based on the DAX empty entry to
locking on the 4k zero page.With the test case reported by Xiong this happens very regularly in my
test setup, with some runs resulting in 9+ threads in this deadlocked
state. With this fix I've been able to run that same test dozens of
times in a loop without issue.Fixes: ac401cc78242 ("dax: New fault locking")
Link: http://lkml.kernel.org/r/1483479365-13607-1-git-send-email-ross.zwisler@linux.intel.com
Signed-off-by: Ross Zwisler
Reported-by: Xiong Zhou
Reviewed-by: Jan Kara
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit b09ab054b69b07077bd3292f67e777861ac796e5 upstream.
zram has used per-cpu stream feature from v4.7. It aims for increasing
cache hit ratio of scratch buffer for compressing. Downside of that
approach is that zram should ask memory space for compressed page in
per-cpu context which requires stricted gfp flag which could be failed.
If so, it retries to allocate memory space out of per-cpu context so it
could get memory this time and compress the data again, copies it to the
memory space.In this scenario, zram assumes the data should never be changed but it is
not true without stable page support. So, If the data is changed under
us, zram can make buffer overrun so that zsmalloc free object chain is
broken so system goes crash like belowhttps://bugzilla.suse.com/show_bug.cgi?id=997574
This patch adds BDI_CAP_STABLE_WRITES to zram for declaring "I am block
device needing *stable write*".Fixes: da9556a2367c ("zram: user per-cpu compression streams")
Link: http://lkml.kernel.org/r/1482366980-3782-4-git-send-email-minchan@kernel.org
Signed-off-by: Minchan Kim
Reviewed-by: Sergey Senozhatsky
Cc: Takashi Iwai
Cc: Hyeoncheol Lee
Cc:
Cc: Sangseok Lee
Cc: Hugh Dickins
Cc: Darrick J. Wong
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit e7ccfc4ccb703e0f033bd4617580039898e912dd upstream.
Commit b4c5c60920e3 ("zram: avoid lockdep splat by revalidate_disk")
moved revalidate_disk call out of init_lock to avoid lockdep
false-positive splat. However, commit 08eee69fcf6b ("zram: remove
init_lock in zram_make_request") removed init_lock in IO path so there
is no worry about lockdep splat. So, let's restore it.This patch is needed to set BDI_CAP_STABLE_WRITES atomically in next
patch.Fixes: da9556a2367c ("zram: user per-cpu compression streams")
Link: http://lkml.kernel.org/r/1482366980-3782-3-git-send-email-minchan@kernel.org
Signed-off-by: Minchan Kim
Reviewed-by: Sergey Senozhatsky
Cc: Takashi Iwai
Cc: Hyeoncheol Lee
Cc:
Cc: Sangseok Lee
Cc: Hugh Dickins
Cc: Darrick J. Wong
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit a2b1e8a20c992b01eeb76de00d4f534cbe9f3822 upstream.
Nothing in this minimal script seems to require bash. We often run these
tests on embedded devices where the only shell available is the busybox
ash. Use sh instead.Signed-off-by: Rolf Eike Beer
Signed-off-by: Shuah Khan
Signed-off-by: Greg Kroah-Hartman -
commit 3659f98b5375d195f1870c3e508fe51e52206839 upstream.
Nothing in this minimal script seems to require bash. We often run these
tests on embedded devices where the only shell available is the busybox
ash. Use sh instead.Signed-off-by: Rolf Eike Beer
Signed-off-by: Shuah Khan
Signed-off-by: Greg Kroah-Hartman -
commit f7741aa75e76440f4e9ecfe512feebe9bce33ca8 upstream.
A recent cleanup changed the kmalloc() + copy_from_user() to
memdup_user() but the error handling wasn't updated so we might call
kfree(-EFAULT) and crash.Fixes: a6e3918bcdb1 ('GPU-DRM-Savage: Use memdup_user() rather than duplicating')
Signed-off-by: Dan Carpenter
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/20161012062227.GU12841@mwanda
Signed-off-by: Greg Kroah-Hartman -
commit b2cdeb19f16ad984eb5bb9193f793d05a8101511 upstream.
If the allocation fails the current code returns success. If
copy_from_user() fails it returns the number of bytes remaining instead
of -EFAULT.Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.")
Signed-off-by: Dan Carpenter
Reviewed-by: Eric Anholt
Signed-off-by: Greg Kroah-Hartman -
commit 9376cad2073d2c122864754ea5f80025c8507b0b upstream.
The devm_pinctrl_register() function returns an error pointer or a valid
handle. So checking for NULL here is pointless and can never trigger.Check the returned value with IS_ERR instead and propagate this value as
done in the other functions which call devm_pinctrl_register().Fixes: 0751bb5c44fe ("drm/tegra: dpaux: Add pinctrl support")
Signed-off-by: Christophe JAILLET
Acked-by: Jon Hunter
Signed-off-by: Thierry Reding
Signed-off-by: Greg Kroah-Hartman -
commit 618c808968852609d2d9f0e5cfc351a4807ef8d0 upstream.
The maximum supported voltage for ldo_io# is 3.3V, but on cold boot
the selector comes up at 0x1f, which maps to 3.8V. This was previously
corrected by Allwinner's U-boot, which set all regulators on the PMICs
to some pre-configured voltage. With recent progress in U-boot SPL
support, this is no longer the case. In any case we should handle
this quirk in the kernel driver as well.This invalid setting causes _regulator_get_voltage() to fail with -EINVAL
which causes regulator registration to fail when constrains are used:[ 1.054181] vcc-pg: failed to get the current voltage(-22)
[ 1.059670] axp20x-regulator axp20x-regulator.0: Failed to register ldo_io0
[ 1.069749] axp20x-regulator: probe of axp20x-regulator.0 failed with error -22This commits makes the axp20x regulator driver accept the 0x1f register
value, fixing this.The datasheet does not guarantee reliable operation above 3.3V, so on
boards where this regulator is used the regulator-max-microvolt setting
must be 3.3V or less.This is essentially the same as the commit f40d4896bf32 ("regulator:
axp20x: Fix axp22x ldo_io registration error on cold boot") for AXP22x
PMICs.Fixes: a51f9f4622a3 ("regulator: axp20x: support AXP809 variant")
Signed-off-by: Chen-Yu Tsai
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit d8ca5bd158f738c4fa6974ee388c381f64db7905 upstream.
The BUCK regulators 3, 4, and 5 also have a 10mV step mode,
adjust the tables and logic to reflect the data-sheet for
these regulators.fixes: d2a2e729a666 ("regulator: tps65086: Add regulator driver for the TPS65086 PMIC")
Signed-off-by: Andrew F. Davis
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit c314c9f15aa5f43f0e5c0e2602cc65798dbd1598 upstream.
On some SoC there are no simple mapping of pins to bias register bits
and a lookup table is needed. This logic is already implemented in some
SoC specific drivers that could benefit from a generic implementation.Add helpers to deal with the lookup which later can be used by the SoC
specific drivers. The logic used to lookup are different from the one it
aims to replace, this is intentional. This new method reduces the memory
consumption at the cost of increased CPU usage and fix a bug where a
WARN() would incorrectly be triggered if the register offset is 0.Signed-off-by: Niklas Söderlund
Reviewed-by: Laurent Pinchart
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Greg Kroah-Hartman -
commit d3b861bccdee2fa9963a2b6c64f74a8d752b9315 upstream.
There is a bug in the r8a7795 bias code where a WARN() is trigged
anytime a pin from PUEN0/PUD0 is accessed.# cat /sys/kernel/debug/pinctrl/e6060000.pfc/pinconf-pins
WARNING: CPU: 2 PID: 2391 at drivers/pinctrl/sh-pfc/pfc-r8a7795.c:5364 r8a7795_pinmux_get_bias+0xbc/0xc8
[..]
Call trace:
[] r8a7795_pinmux_get_bias+0xbc/0xc8
[] sh_pfc_pinconf_get+0x194/0x270
[] pin_config_get_for_pin+0x20/0x30
[] pinconf_generic_dump_one+0x168/0x188
[] pinconf_generic_dump_pins+0x5c/0x98
[] pinconf_pins_show+0xc8/0x128
[] seq_read+0x16c/0x420
[] full_proxy_read+0x58/0x88
[] __vfs_read+0x1c/0xf8
[] vfs_read+0x84/0x148
[] SyS_read+0x44/0xa0
[] __sys_trace_return+0x0/0x4This is due to the WARN() check if the reg field of the pullups struct
is zero, and this should be 0 for pins controlled by the PUEN0/PUD0
registers since PU0 is defined as 0. Change the data structure and use
the generic sh_pfc_pin_to_bias_info() function to get the register
offset and bit information.Fixes: 560655247b627ac7 ("pinctrl: sh-pfc: r8a7795: Add bias pinconf support")
Signed-off-by: Niklas Söderlund
Reviewed-by: Laurent Pinchart
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Greg Kroah-Hartman -
commit 8f5983ad6b81070376db9487ce81000c85a16027 upstream.
Fixes: 6e408ed8be0e ("pinctrl: imx: fix initialization of imx_pinctrl_desc")
Reviewed-by: Vladimir Zapolskiy
Reviewed-by: Peng Fan
Signed-off-by: Gary Bisson
Signed-off-by: Greg Kroah-HartmanSigned-off-by: Linus Walleij
-
commit 41c567a5d7d1a986763e58c3394782813c3bcb03 upstream.
Avoid AUX loopback in Pegatron C15B touchpad, so input subsystem is able
to recognize a Synaptics touchpad in the AUX port.Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=93791
(Touchpad is not detected on DNS 0801480 notebook (PEGATRON C15B))Suggested-by: Dmitry Torokhov
Signed-off-by: Marcos Paulo de Souza
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman -
commit b6fc513da50c5dbc457a8ad6b58b046a6a68fd9d upstream.
currently the controllers get the same product id as the wireless
receiver. However the controllers actually have their own product id.The patch makes the driver expose the same product id as the windows
driver.This improves compatibility when running applications with WINE.
see https://github.com/paroj/xpad/issues/54
Signed-off-by: Pavel Rojtberg
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman
15 Jan, 2017
23 commits
-
commit 60f59ce0278557f7896d5158ae6d12a4855a72cc upstream.
These drivers need to be able to reference "struct ieee80211_hw" from
the driver's private data, and vice versa. The USB driver failed to
store the address of ieee80211_hw in the private data. Although this
bug has been present for a long time, it was not exposed until
commit ba9f93f82aba ("rtlwifi: Fix enter/exit power_save").Fixes: ba9f93f82aba ("rtlwifi: Fix enter/exit power_save")
Signed-off-by: Larry Finger
Signed-off-by: Kalle Valo
Signed-off-by: Greg Kroah-Hartman -
commit ba9f93f82abafe2552eac942ebb11c2df4f8dd7f upstream.
In commit a5ffbe0a1993 ("rtlwifi: Fix scheduling while atomic bug") and
commit a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter()
to use work queue"), an error was introduced in the power-save routines
due to the fact that leaving PS was delayed by the use of a work queue.This problem is fixed by detecting if the enter or leave routines are
in interrupt mode. If so, the workqueue is used to place the request.
If in normal mode, the enter or leave routines are called directly.Fixes: a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter() to use work queue")
Reported-by: Ping-Ke Shih
Signed-off-by: Larry Finger
Cc: Stable
Signed-off-by: Kalle Valo
Signed-off-by: Greg Kroah-Hartman -
commit 2c7d0602c815277f7cb7c932b091288710d8aba7 upstream.
commit 848496e5902833600f7992f4faa82dc1546051ba
Author: Ville Syrjälä
Date: Wed Jul 13 16:32:03 2016 +0300drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL
increased the timeout to match the spec, but we still see a timeout on
at least one SKL. A CDCLK change request following the failed one will
succeed nevertheless.I could reproduce this problem easily by running kms_pipe_crc_basic in a
loop. In all failure cases _wait_for() was pre-empted for >3ms and so in
the worst case - when the pre-emption happened right after calculating
timeout__ in _wait_for() - we called skl_cdclk_wait_for_pcu_ready() only
once which failed and so _wait_for() timed out. As opposed to this the
spec says to keep retrying the request for at most a 3ms period.To fix this send the first request explicitly to guarantee that there is
3ms between the first and last request. Though this matches the spec, I
noticed that in rare cases this can still time out if we sent only a few
requests (in the worst case 2) _and_ PCODE is busy for some reason even
after a previous request and a 3ms delay. To work around this retry the
polling with pre-emption disabled to maximize the number of requests.
Also increase the timeout to 10ms to account for interrupts that could
reduce the number of requests. With this change I couldn't trigger
the problem.v2:
- Use 1ms poll period instead of 10us. (Chris)
v3:
- Poll with pre-emption disabled to increase the number of request
attempts. (Ville, Chris)
- Factor out a helper to poll, it's also needed by the next patch.
v4:
- Pass reply_mask, reply to skl_pcode_request(), instead of assuming the
reply is generic. (Ville)
v5:
- List the request specific timeout values as code comment. (Ville)
v6:
- Try the poll first with preemption enabled.
- Add code comment about first request being queued by PCODE. (Art)
- Add timeout_base_ms argument. (Ville)
v7:
- Clarify code comment about first queued request. (Chris)Cc: Ville Syrjälä
Cc: Chris Wilson
Cc: Art Runyan
Cc: # v4.2- : 3b2c171 : drm/i915: Wait up to 3ms
Cc: # v4.2-
Fixes: 5d96d8afcfbb ("drm/i915/skl: Deinit/init the display at suspend/resume")
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97929
Testcase: igt/kms_pipe_crc_basic/suspend-read-crc-pipe-B
Signed-off-by: Imre Deak
Reviewed-by: Chris Wilson
Link: http://patchwork.freedesktop.org/patch/msgid/1480955258-26311-1-git-send-email-imre.deak@intel.com
(cherry picked from commit a0b8a1fe34430c3a82258e8cb45f5968bdf31afd)
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit 2e40795c3bf344cfb5220d94566205796e3ef19a upstream.
Plantronics BT600 does not support reading the sample rate which leads
to many lines of "cannot get freq at ep 0x1" and "cannot get freq at
ep 0x82". This patch adds the USB ID of the BT600 to quirks.c and
avoids those error messages.Signed-off-by: Dennis Kadioglu
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 7243e0b20729d372e97763617a7a9c89f29b33e1 upstream.
The calculation of SPR and SPPR doesn't round correctly at several
places which might result in baud rates that are too big. For example
with tclk_hz = 250000001 and target rate 25000000 it determined a
divider of 10 which is wrong.Instead of fixing all the corner cases replace the calculation by an
algorithm without a loop which should even be quicker to execute apart
from being correct.Fixes: df59fa7f4bca ("spi: orion: support armada extended baud rates")
Signed-off-by: Uwe Kleine-König
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit f86a2c875fd146d9b82c8fdd86d31084507bcf4c upstream.
The commit 55ee7017ee31 ("arm: omap2: board-generic: use
omap4_local_timer_init for AM437x") unintentionally changes the
clocksource devices for AM437x from OMAP GP Timer to SyncTimer32K.Unfortunately, the SyncTimer32K is starving from frequency deviation
as mentioned in commit 5b5c01359152 ("ARM: OMAP2+: AM43x: Use gptimer
as clocksource") and, as reported by Franklin [1], even its monotonic
nature is under question (most probably there is a HW issue, but it's
still under investigation).Taking into account above facts It's reasonable to rollback to the use
of omap3_gptimer_timer_init().[1] http://www.spinics.net/lists/linux-omap/msg127425.html
Fixes: 55ee7017ee31 ("arm: omap2: board-generic: use
omap4_local_timer_init for AM437x")
Reported-by: Cooper Jr., Franklin
Signed-off-by: Grygorii Strashko
Signed-off-by: Lokesh Vutla
Signed-off-by: Keerthy
Signed-off-by: Tony Lindgren
Signed-off-by: Greg Kroah-Hartman -
commit 9388093db44356af911adf3d355b7544a13a63cd upstream.
Unlike clk_register_clkdev(), clk_hw_register_clkdev() doesn't check for
passed error objects from a previous registration call. Hence the caller
of clk_hw_register_*() has to check for errors before calling
clk_hw_register_clkdev*().Make clk_hw_register_clkdev() more similar to clk_register_clkdev() by
adding this error check, removing the burden from callers that do mass
registration.Fixes: e4f1b49bda6d6aa2 ("clkdev: Add clk_hw based registration APIs")
Fixes: 944b9a41e004534f ("clk: ls1x: Migrate to clk_hw based OF and registration APIs")
Fixes: 44ce9a9ae977736f ("MIPS: TXx9: Convert to Common Clock Framework")
Fixes: f48d947a162dfa9d ("clk: clps711x: Migrate to clk_hw based OF and registration APIs")
Fixes: b4626a7f489238a5 ("CLK: Add Loongson1C clock support")
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman -
commit cbf2642872333547b56b8c4d943f5ed04ac9a4ee upstream.
We don't want to fall through to a bunch of errors for retention
if PM_OMAP4_CPU_OSWR_DISABLE is not configured for a SoC.Fixes: 6099dd37c669 ("ARM: OMAP5 / DRA7: Enable CPU RET on suspend")
Acked-by: Santosh Shilimkar
Signed-off-by: Tony Lindgren
Signed-off-by: Greg Kroah-Hartman -
commit da6d5993bf951846956903bee4f0eafd918250db upstream.
It's CONFIG_SOC_OMAP5, not CONFIG_ARCH_OMAP5. Looks like make randconfig
builds have not hit this one yet.Fixes: b3bf289c1c45 ("ARM: OMAP2+: Fix build with CONFIG_SMP and CONFIG_PM is not set")
Acked-by: Santosh Shilimkar
Signed-off-by: Tony Lindgren
Signed-off-by: Greg Kroah-Hartman -
commit 8a8be46afeaa47aed1debe7e9b18152f9826a6b7 upstream.
We need to properly initialize mpuss also on omap5 like we do on omap4.
Otherwise we run into similar kexec problems like we had on omap4 when
trying to kexec from a kernel with PM initialized.Fixes: 0573b957fc21 ("ARM: OMAP4+: Prevent CPU1 related hang with kexec")
Acked-by: Santosh Shilimkar
Signed-off-by: Tony Lindgren
Signed-off-by: Greg Kroah-Hartman -
commit 26242b330093fd14c2e94fb6cbdf0f482ab26576 upstream.
In case the driver registration fails, the hotplug callback is leaked.
Not fatal, because it's never invoked as there are no instances registered,
but wrong nevertheless.Fixes: fdc15a36d84e ("bus/arm-ccn: Convert to hotplug statemachine")
Signed-off-by: Thomas Gleixner
Cc: Sebastian Andrzej Siewior
Cc: Mark Rutland
Cc: Pawel Moll
Cc: Suzuki K Poulose
Cc: Peter Zijlstra
Cc: Will Deacon
Signed-off-by: Greg Kroah-Hartman -
commit 1b9f700b8cfc31089e2dfa5d0905c52fd4529b50 upstream.
Logic copied from xs_setup_bc_tcp().
Fixes: 39a9beab5acb ('rpc: share one xps between all backchannels')
Signed-off-by: Chuck Lever
Signed-off-by: J. Bruce Fields
Signed-off-by: Greg Kroah-Hartman -
commit 206787737e308bb447d18adef7da7749188212f5 upstream.
Correct prefix is MDM instead of MSM.
Fixes: 8aa788d3e59a ("ARM: configs: qualcomm: Add MDM9615 missing defconfigs")
Signed-off-by: Neil Armstrong
Reviewed-by: Stephen Boyd
Signed-off-by: Andy Gross
Signed-off-by: Greg Kroah-Hartman -
commit 7a3cc2a7b2c723aa552028f4e66841cec183756d upstream.
On Zynq, we haven't been reserving the correct amount of DMA-incapable
RAM to keep DMA away from it (per the Zynq TRM Section 4.1, it should be
the first 512k). In older kernels, this was masked by the
memblock_reserve call in arm_memblock_init(). Now, reserve the correct
amount excplicitly rather than relying on swapper_pg_dir, which is an
address and not a size anyway.Fixes: 46f5b96 ("ARM: zynq: Reserve not DMAable space in front of the kernel")
Signed-off-by: Kyle Roeschley
Tested-by: Nathan Rossi
Signed-off-by: Michal Simek
Signed-off-by: Greg Kroah-Hartman -
commit e413bd33ac44b6d0bebc0ef2ac19cbe7558a7303 upstream.
In the device-tree case, the root interrupt controller cannot be
accessed through the 6th coprocessor, contrary to pxa27x and pxa3xx
architectures.Fix it to behave as in non-devicetree builds.
Fixes: 32f17997c130 ("ARM: pxa: remove irq init from dt machines")
Signed-off-by: Robert Jarzmik
Signed-off-by: Greg Kroah-Hartman -
commit 4f24450c6e580ac8591942c8bf65355a06b44635 upstream.
bcm2837-rpi-3-b.dts, its only in-tree user, was overriding it as
"brcm,bcm2837" already.Fixes: 9d56c22a7861 ("ARM: bcm2835: Add devicetree for the Raspberry Pi 3.")
Cc: Stephen Warren
Signed-off-by: Andreas Färber
Signed-off-by: Eric Anholt
Signed-off-by: Greg Kroah-Hartman -
commit a44e87b47148c6ee6b78509f47e6a15c0fae890a upstream.
We are incorrectly defining the pwr LED, attaching it to a gpio line
that is wired to the Wi-Fi SDIO module (which fails due to this).The actual power LED is connected to the GPIO expander, which we don't
expose currently.Fixes: 9d56c22a7861 ("ARM: bcm2835: Add devicetree for the Raspberry Pi 3.")
Thanks-to: Eric Anholt [for clarifying we can't control the LED]
Signed-off-by: Andrea Merello
Signed-off-by: Eric Anholt
Signed-off-by: Greg Kroah-Hartman -
commit a3207d644fb89e5d7d5e01f00c04dcfc6d2d44d5 upstream.
The devicetree node for mt8173-auxadc lacks the clock and
io-channel-cells property. This leads to a non-working driver.mt6577-auxadc 11001000.auxadc: failed to get auxadc clock
mt6577-auxadc: probe of 11001000.auxadc failed with error -2Fix these fields to get the device up and running.
Fixes: 748c7d4de46a ("ARM64: dts: mt8173: Add thermal/auxadc device
nodes")
Signed-off-by: Matthias Brugger
Signed-off-by: Greg Kroah-Hartman -
commit 5da889c795b1fbefc9d8f058b54717ab8ab17891 upstream.
The virtio tools implementation of READ_ONCE() has a single parameter called
'var', but erroneously refers to 'val' for its cast, and thus won't work unless
there's a variable of the correct type that happens to be called 'var'.Fix this with s/var/val/, making READ_ONCE() work as expected regardless.
Fixes: a7c490333df3cff5 ("tools/virtio: use virt_xxx barriers")
Signed-off-by: Mark Rutland
Cc: Jason Wang
Cc: Michael S. Tsirkin
Cc: linux-kernel@vger.kernel.org
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Michael S. Tsirkin
Reviewed-by: Cornelia Huck
Reviewed-by: Jason Wang
Signed-off-by: Greg Kroah-Hartman -
commit 8ae679c4bc2ea2d16d92620da8e3e9332fa4039f upstream.
I am getting the following warning when I build kernel 4.9-git on my
PowerBook G4 with a 32-bit PPC processor:AS arch/powerpc/kernel/misc_32.o
arch/powerpc/kernel/misc_32.S:299:7: warning: "CONFIG_FSL_BOOKE" is not defined [-Wundef]This problem is evident after commit 989cea5c14be ("kbuild: prevent
lib-ksyms.o rebuilds"); however, this change in kbuild only exposes an
error that has been in the code since 2005 when this source file was
created. That was with commit 9994a33865f4 ("powerpc: Introduce
entry_{32,64}.S, misc_{32,64}.S, systbl.S").The offending line does not make a lot of sense. This error does not
seem to cause any errors in the executable, thus I am not recommending
that it be applied to any stable versions.Thanks to Nicholas Piggin for suggesting this solution.
Fixes: 9994a33865f4 ("powerpc: Introduce entry_{32,64}.S, misc_{32,64}.S, systbl.S")
Signed-off-by: Larry Finger
Cc: Nicholas Piggin
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 6a2a2f45560a9cb7bc49820883b042e44f83726c upstream.
This module has a bug not to return error code in a case that data
structure for transmitted packets fails to be initialized.This commit fixes the bug.
Fixes: 35efa5c489de ("ALSA: firewire-tascam: add streaming functionality")
Signed-off-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 1ebb71143758f45dc0fa76e2f48429e13b16d110 upstream.
Make sure we have enough of a report structure to validate before
looking at it.Reported-by: Benoit Camredon
Tested-by: Benoit Camredon
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Jiri Kosina
