linux.git/arch, branch v5.3.10

arm64: dts: ti: k3-am65-main: Fix gic-its node unit-address

2019-11-10T10:34:59+00:00

commit 389ce1a7c5279ebfb682fab220b4021b2bd49c8b upstream.

The gic-its node unit-address has an additional zero compared
to the actual reg value. Fix it.

Fixes: ea47eed33a3f ("arm64: dts: ti: Add Support for AM654 SoC")
Reported-by: Robert Tivy 
Signed-off-by: Suman Anna 
Signed-off-by: Tero Kristo 
Signed-off-by: Mathieu Poirier 
Signed-off-by: Greg Kroah-Hartman

MIPS: bmips: mark exception vectors as char arrays

2019-11-10T10:34:23+00:00

[ Upstream commit e4f5cb1a9b27c0f94ef4f5a0178a3fde2d3d0e9e ]

The vectors span more than one byte, so mark them as arrays.

Fixes the following build error when building when using GCC 8.3:

In file included from ./include/linux/string.h:19,
                 from ./include/linux/bitmap.h:9,
                 from ./include/linux/cpumask.h:12,
                 from ./arch/mips/include/asm/processor.h:15,
                 from ./arch/mips/include/asm/thread_info.h:16,
                 from ./include/linux/thread_info.h:38,
                 from ./include/asm-generic/preempt.h:5,
                 from ./arch/mips/include/generated/asm/preempt.h:1,
                 from ./include/linux/preempt.h:81,
                 from ./include/linux/spinlock.h:51,
                 from ./include/linux/mmzone.h:8,
                 from ./include/linux/bootmem.h:8,
                 from arch/mips/bcm63xx/prom.c:10:
arch/mips/bcm63xx/prom.c: In function 'prom_init':
./arch/mips/include/asm/string.h:162:11: error: '__builtin_memcpy' forming offset [2, 32] is out of the bounds [0, 1] of object 'bmips_smp_movevec' with type 'char' [-Werror=array-bounds]
   __ret = __builtin_memcpy((dst), (src), __len); \
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/mips/bcm63xx/prom.c:97:3: note: in expansion of macro 'memcpy'
   memcpy((void *)0xa0000200, &bmips_smp_movevec, 0x20);
   ^~~~~~
In file included from arch/mips/bcm63xx/prom.c:14:
./arch/mips/include/asm/bmips.h:80:13: note: 'bmips_smp_movevec' declared here
 extern char bmips_smp_movevec;

Fixes: 18a1eef92dcd ("MIPS: BMIPS: Introduce bmips.h")
Signed-off-by: Jonas Gorski 
Reviewed-by: Florian Fainelli 
Signed-off-by: Paul Burton 
Cc: linux-mips@vger.kernel.org
Cc: Ralf Baechle 
Cc: James Hogan 
Signed-off-by: Sasha Levin

ARM: 8926/1: v7m: remove register save to stack before svc

2019-11-10T10:34:19+00:00

[ Upstream commit 2ecb287998a47cc0a766f6071f63bc185f338540 ]

r0-r3 & r12 registers are saved & restored, before & after svc
respectively. Intention was to preserve those registers across thread to
handler mode switch.

On v7-M, hardware saves the register context upon exception in AAPCS
complaint way. Restoring r0-r3 & r12 is done from stack location where
hardware saves it, not from the location on stack where these registers
were saved.

To clarify, on stm32f429 discovery board:

1. before svc, sp - 0x90009ff8
2. r0-r3,r12 saved to 0x90009ff8 - 0x9000a00b
3. upon svc, h/w decrements sp by 32 & pushes registers onto stack
4. after svc, sp - 0x90009fd8
5. r0-r3,r12 restored from 0x90009fd8 - 0x90009feb

Above means r0-r3,r12 is not restored from the location where they are
saved, but since hardware pushes the registers onto stack, the registers
are restored correctly.

Note that during register saving to stack (step 2), it goes past
0x9000a000. And it seems, based on objdump, there are global symbols
residing there, and it perhaps can cause issues on a non-XIP Kernel
(on XIP, data section is setup later).

Based on the analysis above, manually saving registers onto stack is at
best no-op and at worst can cause data section corruption. Hence remove
storing of registers onto stack before svc.

Fixes: b70cd406d7fe ("ARM: 8671/1: V7M: Preserve registers across switch from Thread to Handler mode")
Signed-off-by: afzal mohammed
Acked-by: Vladimir Murzin
Signed-off-by: Russell King
Signed-off-by: Sasha Levin

ARM: dts: bcm2837-rpi-cm3: Avoid leds-gpio probing issue

2019-11-10T10:34:16+00:00

[ Upstream commit 626c45d223e22090511acbfb481e0ece1de1356d ]

bcm2835-rpi.dtsi defines the behavior of the ACT LED, which is available
on all Raspberry Pi boards. But there is no driver for this particual
GPIO on CM3 in mainline yet, so this node was left incomplete without
the actual GPIO definition. Since commit 025bf37725f1 ("gpio: Fix return
value mismatch of function gpiod_get_from_of_node()") this causing probe
issues of the leds-gpio driver for users of the CM3 dtsi file.

  leds-gpio: probe of leds failed with error -2

Until we have the necessary GPIO driver hide the ACT node for CM3
to avoid this.

Reported-by: Fredrik Yhlen 
Signed-off-by: Stefan Wahren 
Fixes: a54fe8a6cf66 ("ARM: dts: add Raspberry Pi Compute Module 3 and IO board")
Cc: Linus Walleij 
Cc: Krzysztof Kozlowski 
Signed-off-by: Florian Fainelli 
Signed-off-by: Sasha Levin

ARM: davinci: dm365: Fix McBSP dma_slave_map entry

2019-11-10T10:34:11+00:00

[ Upstream commit 564b6bb9d42d31fc80c006658cf38940a9b99616 ]

dm365 have only single McBSP, so the device name is without .0

Fixes: 0c750e1fe481d ("ARM: davinci: dm365: Add dma_slave_map to edma")
Signed-off-by: Peter Ujfalusi 
Signed-off-by: Sekhar Nori 
Signed-off-by: Sasha Levin

arm64: dts: imx8mm: Use correct clock for usdhc's ipg clk

2019-11-10T10:34:09+00:00

[ Upstream commit a6a40d5688f2264afd40574ee1c92e5f824b34ba ]

On i.MX8MM, usdhc's ipg clock is from IMX8MM_CLK_IPG_ROOT,
assign it explicitly instead of using IMX8MM_CLK_DUMMY.

Fixes: a05ea40eb384 ("arm64: dts: imx: Add i.mx8mm dtsi support")
Signed-off-by: Anson Huang 
Signed-off-by: Shawn Guo 
Signed-off-by: Sasha Levin

arm64: dts: imx8mq: Use correct clock for usdhc's ipg clk

2019-11-10T10:34:08+00:00

[ Upstream commit b0759297f2c8dda455ff78a1d1ac95e261300ae3 ]

On i.MX8MQ, usdhc's ipg clock is from IMX8MQ_CLK_IPG_ROOT,
assign it explicitly instead of using IMX8MQ_CLK_DUMMY.

Fixes: 748f908cc882 ("arm64: add basic DTS for i.MX8MQ")
Signed-off-by: Anson Huang 
Signed-off-by: Shawn Guo 
Signed-off-by: Sasha Levin

ARM: dts: imx7s: Correct GPT's ipg clock source

2019-11-10T10:34:08+00:00

[ Upstream commit 252b9e21bcf46b0d16f733f2e42b21fdc60addee ]

i.MX7S/D's GPT ipg clock should be from GPT clock root and
controlled by CCM's GPT CCGR, using correct clock source for
GPT ipg clock instead of IMX7D_CLK_DUMMY.

Fixes: 3ef79ca6bd1d ("ARM: dts: imx7d: use imx7s.dtsi as base device tree")
Signed-off-by: Anson Huang 
Signed-off-by: Shawn Guo 
Signed-off-by: Sasha Levin

ARM: dts: vf610-zii-scu4-aib: Specify 'i2c-mux-idle-disconnect'

2019-11-10T10:34:08+00:00

[ Upstream commit 71936a6d18c33c63b4e9e0359fb987306cbe9fae ]

Specify 'i2c-mux-idle-disconnect' for both I2C switches present on the
board, since both are connected to the same parent bus and all of
their children have the same I2C address.

Fixes: ca4b4d373fcc ("ARM: dts: vf610: Add ZII SCU4 AIB board")
Signed-off-by: Andrey Smirnov 
Cc: Shawn Guo 
Cc: Chris Healy 
Cc: Cory Tusar 
Cc: Jeff White 
Cc: Rick Ramstetter 
Cc: Lucas Stach 
Cc: Fabio Estevam 
Cc: linux-arm-kernel@lists.infradead.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Tested-by: Chris Healy 
Signed-off-by: Shawn Guo 
Signed-off-by: Sasha Levin

ARM: dts: imx6q-logicpd: Re-Enable SNVS power key

2019-11-10T10:34:07+00:00

[ Upstream commit 52f4d4043d1edc4e9e66ec79cae3e32cfe0e44d6 ]

A previous patch disabled the SNVS power key by default which
breaks the ability for the imx6q-logicpd board to wake from sleep.
This patch re-enables this feature for this board.

Fixes: 770856f0da5d ("ARM: dts: imx6qdl: Enable SNVS power key according to board design")
Signed-off-by: Adam Ford 
Signed-off-by: Shawn Guo 
Signed-off-by: Sasha Levin