kernel.git/arch/arm64, branch linux-4.20.y

arm64: dts: hikey: Revert "Enable HS200 mode on eMMC"

2019-03-13T21:04:18Z

commit 8d26c1390aec795d492b8de5e4437751e8805a1d upstream. This reverts commit abd7d0972a192ee653efc7b151a6af69db58f2bb. This change was already partially reverted by John Stultz in commit 9c6d26df1fae ("arm64: dts: hikey: Fix eMMC corruption regression"). This change appears to cause controller resets and block read failures which prevents successful booting on some hikey boards. Cc: Ryan Grachek Cc: Wei Xu Cc: Manivannan Sadhasivam Cc: Rob Herring Cc: Mark Rutland Cc: linux-arm-kernel@lists.infradead.org Cc: devicetree@vger.kernel.org Cc: stable #4.17+ Signed-off-by: Alistair Strachan Signed-off-by: John Stultz Signed-off-by: Wei Xu Signed-off-by: Greg Kroah-Hartman

arm64: dts: hikey: Give wifi some time after power-on

2019-03-13T21:04:18Z

commit 83b944174ad79825ae84a47af1a0354485b24602 upstream. Somewhere along recent changes to power control of the wl1835, power-on became very unreliable on the hikey, failing like this: wl1271_sdio: probe of mmc2:0001:1 failed with error -16 wl1271_sdio: probe of mmc2:0001:2 failed with error -16 After playing with some dt parameters and comparing to other users of this chip, it turned out we need some power-on delay to make things stable again. In contrast to those other users which define 200 ms, the hikey would already be happy with 1 ms. Still, we use the safer 10 ms, like on the Ultra96. Fixes: ea452678734e ("arm64: dts: hikey: Fix WiFi support") Cc: #4.12+ Signed-off-by: Jan Kiszka Acked-by: Ulf Hansson Signed-off-by: Wei Xu Signed-off-by: Greg Kroah-Hartman

arm64: dts: zcu100-revC: Give wifi some time after power-on

2019-03-13T21:04:18Z

commit 35a4f89cd4731ac6ec985cd29ddc1630903006b7 upstream. Somewhere along recent changes to power control of the wl1831, power-on became very unreliable on the Ultra96, failing like this: wl1271_sdio: probe of mmc2:0001:1 failed with error -16 wl1271_sdio: probe of mmc2:0001:2 failed with error -16 After playing with some dt parameters and comparing to other users of this chip, it turned out we need some power-on delay to make things stable again. In contrast to those other users which define 200 ms, Ultra96 is already happy with 10 ms. Fixes: 5869ba0653b9 ("arm64: zynqmp: Add support for Xilinx zcu100-revC") Signed-off-by: Jan Kiszka Acked-by: Ulf Hansson Signed-off-by: Michal Simek Signed-off-by: Greg Kroah-Hartman

arm64: dts: add msm8996 compatible to gicv3

2019-03-13T21:04:11Z

[ Upstream commit 2a81efb0de0e33f2d2c83154af0bd3ce389b3269 ] Add compatible to gicv3 node to enable quirk required to restrict writing to GICR_WAKER register which is restricted on msm8996 SoC in Hypervisor. With this quirk MSM8996 can at least boot out of mainline, which can help community to work with boards based on MSM8996. Without this patch Qualcomm DB820c board reboots on mainline. Signed-off-by: Srinivas Kandagatla Signed-off-by: Andy Gross Signed-off-by: Sasha Levin

arm64: dts: renesas: r8a77965: Enable DMA for SCIF2

2019-03-13T21:04:10Z

[ Upstream commit 05c8478abd485507c25aa565afab604af8d8fe46 ] SCIF2 on R-Car M3-N can be used with both DMAC1 and DMAC2. Fixes: 0ea5b2fd38db56aa ("arm64: dts: renesas: r8a77965: Add SCIF device nodes") Signed-off-by: Geert Uytterhoeven Signed-off-by: Simon Horman Signed-off-by: Sasha Levin

arm64: dts: renesas: r8a7796: Enable DMA for SCIF2

2019-03-13T21:04:10Z

[ Upstream commit 97f26702bc95b5c3a72671d5c6675e4d6ee0a2f4 ] SCIF2 on R-Car M3-W can be used with both DMAC1 and DMAC2. Fixes: dbcae5ea4bd27409 ("arm64: dts: r8a7796: Enable SCIF DMA") Signed-off-by: Geert Uytterhoeven Signed-off-by: Simon Horman Signed-off-by: Sasha Levin

arm64: kprobe: Always blacklist the KVM world-switch code

2019-03-13T21:04:07Z

[ Upstream commit f2b3d8566d81deaca31f4e3163def0bea7746e11 ] On systems with VHE the kernel and KVM's world-switch code run at the same exception level. Code that is only used on a VHE system does not need to be annotated as __hyp_text as it can reside anywhere in the kernel text. __hyp_text was also used to prevent kprobes from patching breakpoint instructions into this region, as this code runs at a different exception level. While this is no longer true with VHE, KVM still switches VBAR_EL1, meaning a kprobe's breakpoint executed in the world-switch code will cause a hyp-panic. Move the __hyp_text check in the kprobes blacklist so it applies on VHE systems too, to cover the common code and guest enter/exit assembly. Fixes: 888b3c8720e0 ("arm64: Treat all entry code as non-kprobe-able") Reviewed-by: Christoffer Dall Signed-off-by: James Morse Acked-by: Masami Hiramatsu Signed-off-by: Will Deacon Signed-off-by: Sasha Levin

arm64: dts: qcom: msm8998: Extend TZ reserved memory area

2019-03-05T16:59:45Z

commit 6e53330909672bd9a8c9f826e989a5945d9d9fdf upstream. My console locks up as soon as Linux writes to [88800000,88f00000[ AFAIU, that memory area is reserved for trustzone. Extend TZ reserved memory range, to prevent Linux from stepping on trustzone's toes. Cc: stable@vger.kernel.org # 4.20+ Reviewed-by: Sibi Sankar Fixes: c7833949564ec ("arm64: dts: qcom: msm8998: Add smem related nodes") Signed-off-by: Marc Gonzalez Signed-off-by: Andy Gross Signed-off-by: Greg Kroah-Hartman

efi/arm: Revert "Defer persistent reservations until after paging_init()"

2019-02-23T08:08:06Z

Commit 582a32e708823e5957fd73ccd78dc4a9e49d21ea upstream. This reverts commit eff896288872d687d9662000ec9ae11b6d61766f, which deferred the processing of persistent memory reservations to a point where the memory may have already been allocated and overwritten, defeating the purpose. Signed-off-by: Ard Biesheuvel Acked-by: Will Deacon Cc: Linus Torvalds Cc: Marc Zyngier Cc: Mike Rapoport Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-arm-kernel@lists.infradead.org Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20190215123333.21209-3-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin

arm64, mm, efi: Account for GICv3 LPI tables in static memblock reserve table

2019-02-23T08:08:06Z

Commit 8a5b403d71affa098009cc3dff1b2c45113021ad upstream. In the irqchip and EFI code, we have what basically amounts to a quirk to work around a peculiarity in the GICv3 architecture, which permits the system memory address of LPI tables to be programmable only once after a CPU reset. This means kexec kernels must use the same memory as the first kernel, and thus ensure that this memory has not been given out for other purposes by the time the ITS init code runs, which is not very early for secondary CPUs. On systems with many CPUs, these reservations could overflow the memblock reservation table, and this was addressed in commit: eff896288872 ("efi/arm: Defer persistent reservations until after paging_init()") However, this turns out to have made things worse, since the allocation of page tables and heap space for the resized memblock reservation table itself may overwrite the regions we are attempting to reserve, which may cause all kinds of corruption, also considering that the ITS will still be poking bits into that memory in response to incoming MSIs. So instead, let's grow the static memblock reservation table on such systems so it can accommodate these reservations at an earlier time. This will permit us to revert the above commit in a subsequent patch. [ mingo: Minor cleanups. ] Signed-off-by: Ard Biesheuvel Acked-by: Mike Rapoport Acked-by: Will Deacon Acked-by: Marc Zyngier Cc: Andrew Morton Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-arm-kernel@lists.infradead.org Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20190215123333.21209-2-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar [ ardb: Double the size of the slack to account for the lack of an optimization that was introduced in mainline after the release of v4.20. ] Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin