summaryrefslogtreecommitdiff
path: root/arch/arm
AgeCommit message (Collapse)Author
2020-10-28ARM: dts: imx6ul: segin: Fix stmpe touchscreen subnode nameStefan Riedmueller
The touchscreen subnode name needs to be stmpe_touchscreen as mentioned in the dt-bindings. Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-10-28ARM: dts: imx7-mba7: set dr_mode to otg on usbotg1Matthias Schiffer
USBOTG1 has a Micro-USB port that can be used in host mode (using an OTG cable) or device mode. Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-10-28ARM: dts: imx7-mba7: specify USB over-current polarityMatthias Schiffer
Add over-current-active-low to usbotg1. Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-10-28ARM: dts: imx7-mba7: enable RS485 on UART7Matthias Schiffer
The UART7 interface is connected to a full-duplex RS485 transceiver. Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-10-28ARM: dts: imx7-mba7: add audio supportMatthias Schiffer
The MBa7x is equipped with a TI TLV320AIC3204 audio codec. Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-10-28ARM: dts: imx7-mba7: update MMC aliasesMatthias Schiffer
Together with the recently merged support for alias-based MMC host numbering, this makes the MMC devices names match what the bootloader expects. Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-10-28ARM: dts: imx7-mba7: configure watchdogMatthias Schiffer
The external watchdog reset is necessary, as the internal reset is unreliable on i.MX7. Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-10-28ARM: dts: imx7-mba7: disable ethernet PHY clock outputsMatthias Schiffer
The clock outputs are not connected. Disable them to improve EMI behaviour. Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-10-28ARM: dts: imx7-mba7: remove unsupported PHY LED setupMatthias Schiffer
These properties were never supported by the DP83867, and a patch implementing them was rejected in favor of a different solution. Remove them. Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-10-28ARM: dts: imx7-mba7: drop incorrect num-chipselects propertyMatthias Schiffer
This property was never set correctly; it should have been num-cs. As num-cs support is being removed as well, simply drop it. Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-10-28ARM: dts: imx7-mba7: update compatible stringsMatthias Schiffer
Include the SoM compatible string. Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-10-28ARM: dts: imx6q-icore-ofcap10: Use 10.1" Ampire panel compatibleJagan Teki
Adding display timings directly on device tree files make it difficult to maintain as a same copy of timings may exist on different files or panel-simple driver. We have a panel-simple driver for this particular usage so supporting on this driver will help to use the same timings on any device tree files if the board mounted on a similar vendor display. Engicam C.TOUCH OF 10.1" LCD board uses Ampire 10.1" TFT LCD and it has supported by panel-simple already, so simply use that binding. Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-10-28ARM: dts: Fix label address for 64MiB OpenBMC flash layoutGeorge Liu
Signed-off-by: George Liu <liuxiwei@inspur.com> Reviewed-by: John Wang <wangzhiqiang.bj@bytedance.com> Acked-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20201022081002.2665132-1-liuxiwei@inspur.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2020-10-28ARM: dts: aspeed: g220a: Add some gpiosJohn Wang
Add GPIO STRAP_BMC_BATTERY_GPIOS5, which is used for battery adc sensor. Change the INTRUDER_N to CHASSIS_INTRUSION, to make it more meaningful. Signed-off-by: John Wang <wangzhiqiang.bj@bytedance.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20201014083057.1026-1-wangzhiqiang.bj@bytedance.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2020-10-28ARM: dts: aspeed: Add Bytedance g220a BMC machineLotus Xu
The g220a is a server platform with an ASPEED AST2500 BMC. Signed-off-by: Lotus Xu <xuxiaohan@bytedance.com> Signed-off-by: John Wang <wangzhiqiang.bj@bytedance.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20200929063955.1206-2-wangzhiqiang.bj@bytedance.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2020-10-28ARM: dts: Add 64MiB OpenBMC flash layoutJohn Wang
This is an alternate layout used by OpenBMC systems The division of space is as follows: u-boot + env: 0.5MB kernel/FIT: 5MB rofs: 42.5MB rwfs: 16MB Signed-off-by: John Wang <wangzhiqiang.bj@bytedance.com> Link: https://lore.kernel.org/r/20200929063955.1206-1-wangzhiqiang.bj@bytedance.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2020-10-28ARM: dts: aspeed: s2600wf: Fix VGA memory region locationJoel Stanley
The VGA memory region is always from the top of RAM. On this board, that is 0x80000000 + 0x20000000 - 0x01000000 = 0x9f000000. This was not an issue in practice as the region is "reserved" by the vendor's u-boot reducing the amount of available RAM, and the only user is the host VGA device poking at RAM over PCIe. That is, nothing from the ARM touches it. It is worth fixing as developers copy existing device trees when building their machines, and the XDMA driver does use the memory region from the ARM side. Fixes: c4043ecac34a ("ARM: dts: aspeed: Add S2600WF BMC Machine") Reported-by: John Wang <wangzhiqiang.bj@bytedance.com> Link: https://lore.kernel.org/r/20200922064234.163799-1-joel@jms.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
2020-10-28ARM: dts: aspeed: amd-ethanolx: Update KCS nodes to use v2 bindingKonstantin Aladyshev
KCS nodes compatible property was changed in the dtsi to use v2 binding before ethanolx was merged, making the ethanolx device tree incorrect. Update it to use the new binding so the driver loads. Fixes: fa4c8ec6feaa ("ARM: dts: aspeed: Change KCS nodes to v2 binding") Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20201027123722.2935-1-aladyshev22@gmail.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2020-10-28ARM: dts: aspeed-g6: Fix the GPIO memory sizeBilly Tsai
The GPIO controller is a GPIO controller followed by some SGPIO controllers, which are a different type of device with their own binding and drivers. Make the gpio node cover the only conventional GPIO controller. Fixes: 8dbcb5b709b9 ("ARM: dts: aspeed-g6: Add gpio devices") Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20201012033150.21056-2-billy_tsai@aspeedtech.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2020-10-27arm/build: Always handle .ARM.exidx and .ARM.extab sectionsNathan Chancellor
After turning on warnings for orphan section placement, enabling CONFIG_UNWINDER_FRAME_POINTER instead of CONFIG_UNWINDER_ARM causes thousands of warnings when clang + ld.lld are used: $ scripts/config --file arch/arm/configs/multi_v7_defconfig \ -d CONFIG_UNWINDER_ARM \ -e CONFIG_UNWINDER_FRAME_POINTER $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 defconfig zImage ld.lld: warning: init/built-in.a(main.o):(.ARM.extab) is being placed in '.ARM.extab' ld.lld: warning: init/built-in.a(main.o):(.ARM.extab.init.text) is being placed in '.ARM.extab.init.text' ld.lld: warning: init/built-in.a(main.o):(.ARM.extab.ref.text) is being placed in '.ARM.extab.ref.text' ld.lld: warning: init/built-in.a(do_mounts.o):(.ARM.extab.init.text) is being placed in '.ARM.extab.init.text' ld.lld: warning: init/built-in.a(do_mounts.o):(.ARM.extab) is being placed in '.ARM.extab' ld.lld: warning: init/built-in.a(do_mounts_rd.o):(.ARM.extab.init.text) is being placed in '.ARM.extab.init.text' ld.lld: warning: init/built-in.a(do_mounts_rd.o):(.ARM.extab) is being placed in '.ARM.extab' ld.lld: warning: init/built-in.a(do_mounts_initrd.o):(.ARM.extab.init.text) is being placed in '.ARM.extab.init.text' ld.lld: warning: init/built-in.a(initramfs.o):(.ARM.extab.init.text) is being placed in '.ARM.extab.init.text' ld.lld: warning: init/built-in.a(initramfs.o):(.ARM.extab) is being placed in '.ARM.extab' ld.lld: warning: init/built-in.a(calibrate.o):(.ARM.extab.init.text) is being placed in '.ARM.extab.init.text' ld.lld: warning: init/built-in.a(calibrate.o):(.ARM.extab) is being placed in '.ARM.extab' These sections are handled by the ARM_UNWIND_SECTIONS define, which is only added to the list of sections when CONFIG_ARM_UNWIND is set. CONFIG_ARM_UNWIND is a hidden symbol that is only selected when CONFIG_UNWINDER_ARM is set so CONFIG_UNWINDER_FRAME_POINTER never handles these sections. According to the help text of CONFIG_UNWINDER_ARM, these sections should be discarded so that the kernel image size is not affected. Fixes: 5a17850e251a ("arm/build: Warn on orphan section placement") Link: https://github.com/ClangBuiltLinux/linux/issues/1152 Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Review-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> [kees: Made the discard slightly more specific] Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20200928224854.3224862-1-natechancellor@gmail.com
2020-10-27ARM: dts: exynos: Remove 'opp-shared' from Exynos4412 bus OPP-tablesMarek Szyprowski
Commits 1019fe2c7280 ("ARM: dts: exynos: Adjust bus related OPPs to the values correct for Exynos5422 Odroids") and 9ff416cf45a0 ("ARM: dts: exynos: Disable frequency scaling for FSYS bus on Odroid XU3 family") revealed that 'opp-shared' property for the Exynos bus OPPs was used incorrectly, what had the side-effect of disabling frequency scaling for the second and latter buses sharing given OPP-table. Fix this by removing bogus 'opp-shared' properties from Exynos4412 bus OPP-tables. This restores frequency scaling for the following buses: C2C, RightBus, and MFC. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20200911122236.16805-1-m.szyprowski@samsung.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2020-10-27ARM: dts: exynos: Remove 'opp-shared' from Exynos3 bus OPP-tablesMarek Szyprowski
Commits 1019fe2c7280 ("ARM: dts: exynos: Adjust bus related OPPs to the values correct for Exynos5422 Odroids") and 9ff416cf45a0 ("ARM: dts: exynos: Disable frequency scaling for FSYS bus on Odroid XU3 family") revealed that 'opp-shared' property for the Exynos bus OPPs was used incorrectly, what had the side-effect of disabling frequency scaling for the second and latter buses sharing given OPP-table. Fix this by removing bogus 'opp-shared' properties from Exynos3 bus OPP-tables. This restores frequency scaling for the following buses: RightBus, LCD0, FSYS and MFC. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20200911122220.13698-1-m.szyprowski@samsung.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2020-10-27ARM: dts: sun8i: add FriendlyArm ZeroPi supportYu-Tung Chang
The ZeroPi is another fun board developed by FriendlyELEC for makers, hobbyists and fans. ZeroPi key features - Allwinner H3, Quad-core Cortex-A7@1.2GHz - 256MB/512MB DDR3 RAM - microsd slot - 10/100/1000Mbps Ethernet - Debug Serial Port - DC 5V/2A power-supply Signed-off-by: Yu-Tung Chang <mtwget@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20201026073536.13617-2-mtwget@gmail.com
2020-10-27ARM: 9019/1: kprobes: Avoid fortify_panic() when copying optprobe templateAndrew Jeffery
Setting both CONFIG_KPROBES=y and CONFIG_FORTIFY_SOURCE=y on ARM leads to a panic in memcpy() when injecting a kprobe despite the fixes found in commit e46daee53bb5 ("ARM: 8806/1: kprobes: Fix false positive with FORTIFY_SOURCE") and commit 0ac569bf6a79 ("ARM: 8834/1: Fix: kprobes: optimized kprobes illegal instruction"). arch/arm/include/asm/kprobes.h effectively declares the target type of the optprobe_template_entry assembly label as a u32 which leads memcpy()'s __builtin_object_size() call to determine that the pointed-to object is of size four. However, the symbol is used as a handle for the optimised probe assembly template that is at least 96 bytes in size. The symbol's use despite its type blows up the memcpy() in ARM's arch_prepare_optimized_kprobe() with a false-positive fortify_panic() when it should instead copy the optimised probe template into place: ``` $ sudo perf probe -a aspeed_g6_pinctrl_probe [ 158.457252] detected buffer overflow in memcpy [ 158.458069] ------------[ cut here ]------------ [ 158.458283] kernel BUG at lib/string.c:1153! [ 158.458436] Internal error: Oops - BUG: 0 [#1] SMP ARM [ 158.458768] Modules linked in: [ 158.459043] CPU: 1 PID: 99 Comm: perf Not tainted 5.9.0-rc7-00038-gc53ebf8167e9 #158 [ 158.459296] Hardware name: Generic DT based system [ 158.459529] PC is at fortify_panic+0x18/0x20 [ 158.459658] LR is at __irq_work_queue_local+0x3c/0x74 [ 158.459831] pc : [<8047451c>] lr : [<8020ecd4>] psr: 60000013 [ 158.460032] sp : be2d1d50 ip : be2d1c58 fp : be2d1d5c [ 158.460174] r10: 00000006 r9 : 00000000 r8 : 00000060 [ 158.460348] r7 : 8011e434 r6 : b9e0b800 r5 : 7f000000 r4 : b9fe4f0c [ 158.460557] r3 : 80c04cc8 r2 : 00000000 r1 : be7c03cc r0 : 00000022 [ 158.460801] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 158.461037] Control: 10c5387d Table: b9cd806a DAC: 00000051 [ 158.461251] Process perf (pid: 99, stack limit = 0x81c71a69) [ 158.461472] Stack: (0xbe2d1d50 to 0xbe2d2000) [ 158.461757] 1d40: be2d1d84 be2d1d60 8011e724 80474510 [ 158.462104] 1d60: b9e0b800 b9fe4f0c 00000000 b9fe4f14 80c8ec80 be235000 be2d1d9c be2d1d88 [ 158.462436] 1d80: 801cee44 8011e57c b9fe4f0c 00000000 be2d1dc4 be2d1da0 801d0ad0 801cedec [ 158.462742] 1da0: 00000000 00000000 b9fe4f00 ffffffea 00000000 be235000 be2d1de4 be2d1dc8 [ 158.463087] 1dc0: 80204604 801d0738 00000000 00000000 b9fe4004 ffffffea be2d1e94 be2d1de8 [ 158.463428] 1de0: 80205434 80204570 00385c00 00000000 00000000 00000000 be2d1e14 be2d1e08 [ 158.463880] 1e00: 802ba014 b9fe4f00 b9e718c0 b9fe4f84 b9e71ec8 be2d1e24 00000000 00385c00 [ 158.464365] 1e20: 00000000 626f7270 00000065 802b905c be2d1e94 0000002e 00000000 802b9914 [ 158.464829] 1e40: be2d1e84 be2d1e50 802b9914 8028ff78 804629d0 b9e71ec0 0000002e b9e71ec0 [ 158.465141] 1e60: be2d1ea8 80c04cc8 00000cc0 b9e713c4 00000002 80205834 80205834 0000002e [ 158.465488] 1e80: be235000 be235000 be2d1ea4 be2d1e98 80205854 80204e94 be2d1ecc be2d1ea8 [ 158.465806] 1ea0: 801ee4a0 80205840 00000002 80c04cc8 00000000 0000002e 0000002e 00000000 [ 158.466110] 1ec0: be2d1f0c be2d1ed0 801ee5c8 801ee428 00000000 be2d0000 006b1fd0 00000051 [ 158.466398] 1ee0: 00000000 b9eedf00 0000002e 80204410 006b1fd0 be2d1f60 00000000 00000004 [ 158.466763] 1f00: be2d1f24 be2d1f10 8020442c 801ee4c4 80205834 802c613c be2d1f5c be2d1f28 [ 158.467102] 1f20: 802c60ac 8020441c be2d1fac be2d1f38 8010c764 802e9888 be2d1f5c b9eedf00 [ 158.467447] 1f40: b9eedf00 006b1fd0 0000002e 00000000 be2d1f94 be2d1f60 802c634c 802c5fec [ 158.467812] 1f60: 00000000 00000000 00000000 80c04cc8 006b1fd0 00000003 76f7a610 00000004 [ 158.468155] 1f80: 80100284 be2d0000 be2d1fa4 be2d1f98 802c63ec 802c62e8 00000000 be2d1fa8 [ 158.468508] 1fa0: 80100080 802c63e0 006b1fd0 00000003 00000003 006b1fd0 0000002e 00000000 [ 158.468858] 1fc0: 006b1fd0 00000003 76f7a610 00000004 006b1fb0 0026d348 00000017 7ef2738c [ 158.469202] 1fe0: 76f3431c 7ef272d8 0014ec50 76f34338 60000010 00000003 00000000 00000000 [ 158.469461] Backtrace: [ 158.469683] [<80474504>] (fortify_panic) from [<8011e724>] (arch_prepare_optimized_kprobe+0x1b4/0x1f8) [ 158.470021] [<8011e570>] (arch_prepare_optimized_kprobe) from [<801cee44>] (alloc_aggr_kprobe+0x64/0x70) [ 158.470287] r9:be235000 r8:80c8ec80 r7:b9fe4f14 r6:00000000 r5:b9fe4f0c r4:b9e0b800 [ 158.470478] [<801cede0>] (alloc_aggr_kprobe) from [<801d0ad0>] (register_kprobe+0x3a4/0x5a0) [ 158.470685] r5:00000000 r4:b9fe4f0c [ 158.470790] [<801d072c>] (register_kprobe) from [<80204604>] (__register_trace_kprobe+0xa0/0xa4) [ 158.471001] r9:be235000 r8:00000000 r7:ffffffea r6:b9fe4f00 r5:00000000 r4:00000000 [ 158.471188] [<80204564>] (__register_trace_kprobe) from [<80205434>] (trace_kprobe_create+0x5ac/0x9ac) [ 158.471408] r7:ffffffea r6:b9fe4004 r5:00000000 r4:00000000 [ 158.471553] [<80204e88>] (trace_kprobe_create) from [<80205854>] (create_or_delete_trace_kprobe+0x20/0x3c) [ 158.471766] r10:be235000 r9:be235000 r8:0000002e r7:80205834 r6:80205834 r5:00000002 [ 158.471949] r4:b9e713c4 [ 158.472027] [<80205834>] (create_or_delete_trace_kprobe) from [<801ee4a0>] (trace_run_command+0x84/0x9c) [ 158.472255] [<801ee41c>] (trace_run_command) from [<801ee5c8>] (trace_parse_run_command+0x110/0x1f8) [ 158.472471] r6:00000000 r5:0000002e r4:0000002e [ 158.472594] [<801ee4b8>] (trace_parse_run_command) from [<8020442c>] (probes_write+0x1c/0x28) [ 158.472800] r10:00000004 r9:00000000 r8:be2d1f60 r7:006b1fd0 r6:80204410 r5:0000002e [ 158.472968] r4:b9eedf00 [ 158.473046] [<80204410>] (probes_write) from [<802c60ac>] (vfs_write+0xcc/0x1e8) [ 158.473226] [<802c5fe0>] (vfs_write) from [<802c634c>] (ksys_write+0x70/0xf8) [ 158.473400] r8:00000000 r7:0000002e r6:006b1fd0 r5:b9eedf00 r4:b9eedf00 [ 158.473567] [<802c62dc>] (ksys_write) from [<802c63ec>] (sys_write+0x18/0x1c) [ 158.473745] r9:be2d0000 r8:80100284 r7:00000004 r6:76f7a610 r5:00000003 r4:006b1fd0 [ 158.473932] [<802c63d4>] (sys_write) from [<80100080>] (ret_fast_syscall+0x0/0x54) [ 158.474126] Exception stack(0xbe2d1fa8 to 0xbe2d1ff0) [ 158.474305] 1fa0: 006b1fd0 00000003 00000003 006b1fd0 0000002e 00000000 [ 158.474573] 1fc0: 006b1fd0 00000003 76f7a610 00000004 006b1fb0 0026d348 00000017 7ef2738c [ 158.474811] 1fe0: 76f3431c 7ef272d8 0014ec50 76f34338 [ 158.475171] Code: e24cb004 e1a01000 e59f0004 ebf40dd3 (e7f001f2) [ 158.475847] ---[ end trace 55a5b31c08a29f00 ]--- [ 158.476088] Kernel panic - not syncing: Fatal exception [ 158.476375] CPU0: stopping [ 158.476709] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G D 5.9.0-rc7-00038-gc53ebf8167e9 #158 [ 158.477176] Hardware name: Generic DT based system [ 158.477411] Backtrace: [ 158.477604] [<8010dd28>] (dump_backtrace) from [<8010dfd4>] (show_stack+0x20/0x24) [ 158.477990] r7:00000000 r6:60000193 r5:00000000 r4:80c2f634 [ 158.478323] [<8010dfb4>] (show_stack) from [<8046390c>] (dump_stack+0xcc/0xe8) [ 158.478686] [<80463840>] (dump_stack) from [<80110750>] (handle_IPI+0x334/0x3a0) [ 158.479063] r7:00000000 r6:00000004 r5:80b65cc8 r4:80c78278 [ 158.479352] [<8011041c>] (handle_IPI) from [<801013f8>] (gic_handle_irq+0x88/0x94) [ 158.479757] r10:10c5387d r9:80c01ed8 r8:00000000 r7:c0802000 r6:80c0537c r5:000003ff [ 158.480146] r4:c080200c r3:fffffff4 [ 158.480364] [<80101370>] (gic_handle_irq) from [<80100b6c>] (__irq_svc+0x6c/0x90) [ 158.480748] Exception stack(0x80c01ed8 to 0x80c01f20) [ 158.481031] 1ec0: 000128bc 00000000 [ 158.481499] 1ee0: be7b8174 8011d3a0 80c00000 00000000 80c04cec 80c04d28 80c5d7c2 80a026d4 [ 158.482091] 1f00: 10c5387d 80c01f34 80c01f38 80c01f28 80109554 80109558 60000013 ffffffff [ 158.482621] r9:80c00000 r8:80c5d7c2 r7:80c01f0c r6:ffffffff r5:60000013 r4:80109558 [ 158.482983] [<80109518>] (arch_cpu_idle) from [<80818780>] (default_idle_call+0x38/0x120) [ 158.483360] [<80818748>] (default_idle_call) from [<801585a8>] (do_idle+0xd4/0x158) [ 158.483945] r5:00000000 r4:80c00000 [ 158.484237] [<801584d4>] (do_idle) from [<801588f4>] (cpu_startup_entry+0x28/0x2c) [ 158.484784] r9:80c78000 r8:00000000 r7:80c78000 r6:80c78040 r5:80c04cc0 r4:000000d6 [ 158.485328] [<801588cc>] (cpu_startup_entry) from [<80810a78>] (rest_init+0x9c/0xbc) [ 158.485930] [<808109dc>] (rest_init) from [<80b00ae4>] (arch_call_rest_init+0x18/0x1c) [ 158.486503] r5:80c04cc0 r4:00000001 [ 158.486857] [<80b00acc>] (arch_call_rest_init) from [<80b00fcc>] (start_kernel+0x46c/0x548) [ 158.487589] [<80b00b60>] (start_kernel) from [<00000000>] (0x0) ``` Fixes: e46daee53bb5 ("ARM: 8806/1: kprobes: Fix false positive with FORTIFY_SOURCE") Fixes: 0ac569bf6a79 ("ARM: 8834/1: Fix: kprobes: optimized kprobes illegal instruction") Suggested-by: Kees Cook <keescook@chromium.org> Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Tested-by: Luka Oreskovic <luka.oreskovic@sartura.hr> Tested-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Acked-by: Masami Hiramatsu <mhiramat@kernel.org> Cc: Luka Oreskovic <luka.oreskovic@sartura.hr> Cc: Juraj Vijtiuk <juraj.vijtiuk@sartura.hr> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-10-27ARM: 9017/2: Enable KASan for ARMLinus Walleij
This patch enables the kernel address sanitizer for ARM. XIP_KERNEL has not been tested and is therefore not allowed for now. Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Alexander Potapenko <glider@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: kasan-dev@googlegroups.com Acked-by: Dmitry Vyukov <dvyukov@google.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Ard Biesheuvel <ardb@kernel.org> # QEMU/KVM/mach-virt/LPAE/8G Tested-by: Florian Fainelli <f.fainelli@gmail.com> # Brahma SoCs Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # i.MX6Q Signed-off-by: Abbott Liu <liuwenliang@huawei.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-10-27ARM: 9016/2: Initialize the mapping of KASan shadow memoryLinus Walleij
This patch initializes KASan shadow region's page table and memory. There are two stage for KASan initializing: 1. At early boot stage the whole shadow region is mapped to just one physical page (kasan_zero_page). It is finished by the function kasan_early_init which is called by __mmap_switched(arch/arm/kernel/ head-common.S) 2. After the calling of paging_init, we use kasan_zero_page as zero shadow for some memory that KASan does not need to track, and we allocate a new shadow space for the other memory that KASan need to track. These issues are finished by the function kasan_init which is call by setup_arch. When using KASan we also need to increase the THREAD_SIZE_ORDER from 1 to 2 as the extra calls for shadow memory uses quite a bit of stack. As we need to make a temporary copy of the PGD when setting up shadow memory we create a helpful PGD_SIZE definition for both LPAE and non-LPAE setups. The KASan core code unconditionally calls pud_populate() so this needs to be changed from BUG() to do {} while (0) when building with KASan enabled. After the initial development by Andre Ryabinin several modifications have been made to this code: Abbott Liu <liuwenliang@huawei.com> - Add support ARM LPAE: If LPAE is enabled, KASan shadow region's mapping table need be copied in the pgd_alloc() function. - Change kasan_pte_populate,kasan_pmd_populate,kasan_pud_populate, kasan_pgd_populate from .meminit.text section to .init.text section. Reported by Florian Fainelli <f.fainelli@gmail.com> Linus Walleij <linus.walleij@linaro.org>: - Drop the custom mainpulation of TTBR0 and just use cpu_switch_mm() to switch the pgd table. - Adopt to handle 4th level page tabel folding. - Rewrite the entire page directory and page entry initialization sequence to be recursive based on ARM64:s kasan_init.c. Ard Biesheuvel <ardb@kernel.org>: - Necessary underlying fixes. - Crucial bug fixes to the memory set-up code. Co-developed-by: Andrey Ryabinin <aryabinin@virtuozzo.com> Co-developed-by: Abbott Liu <liuwenliang@huawei.com> Co-developed-by: Ard Biesheuvel <ardb@kernel.org> Cc: Alexander Potapenko <glider@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: kasan-dev@googlegroups.com Cc: Mike Rapoport <rppt@linux.ibm.com> Acked-by: Mike Rapoport <rppt@linux.ibm.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Ard Biesheuvel <ardb@kernel.org> # QEMU/KVM/mach-virt/LPAE/8G Tested-by: Florian Fainelli <f.fainelli@gmail.com> # Brahma SoCs Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # i.MX6Q Reported-by: Russell King - ARM Linux <rmk+kernel@armlinux.org.uk> Reported-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com> Signed-off-by: Abbott Liu <liuwenliang@huawei.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-10-27ARM: 9015/2: Define the virtual space of KASan's shadow regionLinus Walleij
Define KASAN_SHADOW_OFFSET,KASAN_SHADOW_START and KASAN_SHADOW_END for the Arm kernel address sanitizer. We are "stealing" lowmem (the 4GB addressable by a 32bit architecture) out of the virtual address space to use as shadow memory for KASan as follows: +----+ 0xffffffff | | | | |-> Static kernel image (vmlinux) BSS and page table | |/ +----+ PAGE_OFFSET | | | | |-> Loadable kernel modules virtual address space area | |/ +----+ MODULES_VADDR = KASAN_SHADOW_END | | | | |-> The shadow area of kernel virtual address. | |/ +----+-> TASK_SIZE (start of kernel space) = KASAN_SHADOW_START the | | shadow address of MODULES_VADDR | | | | | | | | |-> The user space area in lowmem. The kernel address | | | sanitizer do not use this space, nor does it map it. | | | | | | | | | | | | | |/ ------ 0 0 .. TASK_SIZE is the memory that can be used by shared userspace/kernelspace. It us used for userspace processes and for passing parameters and memory buffers in system calls etc. We do not need to shadow this area. KASAN_SHADOW_START: This value begins with the MODULE_VADDR's shadow address. It is the start of kernel virtual space. Since we have modules to load, we need to cover also that area with shadow memory so we can find memory bugs in modules. KASAN_SHADOW_END This value is the 0x100000000's shadow address: the mapping that would be after the end of the kernel memory at 0xffffffff. It is the end of kernel address sanitizer shadow area. It is also the start of the module area. KASAN_SHADOW_OFFSET: This value is used to map an address to the corresponding shadow address by the following formula: shadow_addr = (address >> 3) + KASAN_SHADOW_OFFSET; As you would expect, >> 3 is equal to dividing by 8, meaning each byte in the shadow memory covers 8 bytes of kernel memory, so one bit shadow memory per byte of kernel memory is used. The KASAN_SHADOW_OFFSET is provided in a Kconfig option depending on the VMSPLIT layout of the system: the kernel and userspace can split up lowmem in different ways according to needs, so we calculate the shadow offset depending on this. When kasan is enabled, the definition of TASK_SIZE is not an 8-bit rotated constant, so we need to modify the TASK_SIZE access code in the *.s file. The kernel and modules may use different amounts of memory, according to the VMSPLIT configuration, which in turn determines the PAGE_OFFSET. We use the following KASAN_SHADOW_OFFSETs depending on how the virtual memory is split up: - 0x1f000000 if we have 1G userspace / 3G kernelspace split: - The kernel address space is 3G (0xc0000000) - PAGE_OFFSET is then set to 0x40000000 so the kernel static image (vmlinux) uses addresses 0x40000000 .. 0xffffffff - On top of that we have the MODULES_VADDR which under the worst case (using ARM instructions) is PAGE_OFFSET - 16M (0x01000000) = 0x3f000000 so the modules use addresses 0x3f000000 .. 0x3fffffff - So the addresses 0x3f000000 .. 0xffffffff need to be covered with shadow memory. That is 0xc1000000 bytes of memory. - 1/8 of that is needed for its shadow memory, so 0x18200000 bytes of shadow memory is needed. We "steal" that from the remaining lowmem. - The KASAN_SHADOW_START becomes 0x26e00000, to KASAN_SHADOW_END at 0x3effffff. - Now we can calculate the KASAN_SHADOW_OFFSET for any kernel address as 0x3f000000 needs to map to the first byte of shadow memory and 0xffffffff needs to map to the last byte of shadow memory. Since: SHADOW_ADDR = (address >> 3) + KASAN_SHADOW_OFFSET 0x26e00000 = (0x3f000000 >> 3) + KASAN_SHADOW_OFFSET KASAN_SHADOW_OFFSET = 0x26e00000 - (0x3f000000 >> 3) KASAN_SHADOW_OFFSET = 0x26e00000 - 0x07e00000 KASAN_SHADOW_OFFSET = 0x1f000000 - 0x5f000000 if we have 2G userspace / 2G kernelspace split: - The kernel space is 2G (0x80000000) - PAGE_OFFSET is set to 0x80000000 so the kernel static image uses 0x80000000 .. 0xffffffff. - On top of that we have the MODULES_VADDR which under the worst case (using ARM instructions) is PAGE_OFFSET - 16M (0x01000000) = 0x7f000000 so the modules use addresses 0x7f000000 .. 0x7fffffff - So the addresses 0x7f000000 .. 0xffffffff need to be covered with shadow memory. That is 0x81000000 bytes of memory. - 1/8 of that is needed for its shadow memory, so 0x10200000 bytes of shadow memory is needed. We "steal" that from the remaining lowmem. - The KASAN_SHADOW_START becomes 0x6ee00000, to KASAN_SHADOW_END at 0x7effffff. - Now we can calculate the KASAN_SHADOW_OFFSET for any kernel address as 0x7f000000 needs to map to the first byte of shadow memory and 0xffffffff needs to map to the last byte of shadow memory. Since: SHADOW_ADDR = (address >> 3) + KASAN_SHADOW_OFFSET 0x6ee00000 = (0x7f000000 >> 3) + KASAN_SHADOW_OFFSET KASAN_SHADOW_OFFSET = 0x6ee00000 - (0x7f000000 >> 3) KASAN_SHADOW_OFFSET = 0x6ee00000 - 0x0fe00000 KASAN_SHADOW_OFFSET = 0x5f000000 - 0x9f000000 if we have 3G userspace / 1G kernelspace split, and this is the default split for ARM: - The kernel address space is 1GB (0x40000000) - PAGE_OFFSET is set to 0xc0000000 so the kernel static image uses 0xc0000000 .. 0xffffffff. - On top of that we have the MODULES_VADDR which under the worst case (using ARM instructions) is PAGE_OFFSET - 16M (0x01000000) = 0xbf000000 so the modules use addresses 0xbf000000 .. 0xbfffffff - So the addresses 0xbf000000 .. 0xffffffff need to be covered with shadow memory. That is 0x41000000 bytes of memory. - 1/8 of that is needed for its shadow memory, so 0x08200000 bytes of shadow memory is needed. We "steal" that from the remaining lowmem. - The KASAN_SHADOW_START becomes 0xb6e00000, to KASAN_SHADOW_END at 0xbfffffff. - Now we can calculate the KASAN_SHADOW_OFFSET for any kernel address as 0xbf000000 needs to map to the first byte of shadow memory and 0xffffffff needs to map to the last byte of shadow memory. Since: SHADOW_ADDR = (address >> 3) + KASAN_SHADOW_OFFSET 0xb6e00000 = (0xbf000000 >> 3) + KASAN_SHADOW_OFFSET KASAN_SHADOW_OFFSET = 0xb6e00000 - (0xbf000000 >> 3) KASAN_SHADOW_OFFSET = 0xb6e00000 - 0x17e00000 KASAN_SHADOW_OFFSET = 0x9f000000 - 0x8f000000 if we have 3G userspace / 1G kernelspace with full 1 GB low memory (VMSPLIT_3G_OPT): - The kernel address space is 1GB (0x40000000) - PAGE_OFFSET is set to 0xb0000000 so the kernel static image uses 0xb0000000 .. 0xffffffff. - On top of that we have the MODULES_VADDR which under the worst case (using ARM instructions) is PAGE_OFFSET - 16M (0x01000000) = 0xaf000000 so the modules use addresses 0xaf000000 .. 0xaffffff - So the addresses 0xaf000000 .. 0xffffffff need to be covered with shadow memory. That is 0x51000000 bytes of memory. - 1/8 of that is needed for its shadow memory, so 0x0a200000 bytes of shadow memory is needed. We "steal" that from the remaining lowmem. - The KASAN_SHADOW_START becomes 0xa4e00000, to KASAN_SHADOW_END at 0xaeffffff. - Now we can calculate the KASAN_SHADOW_OFFSET for any kernel address as 0xaf000000 needs to map to the first byte of shadow memory and 0xffffffff needs to map to the last byte of shadow memory. Since: SHADOW_ADDR = (address >> 3) + KASAN_SHADOW_OFFSET 0xa4e00000 = (0xaf000000 >> 3) + KASAN_SHADOW_OFFSET KASAN_SHADOW_OFFSET = 0xa4e00000 - (0xaf000000 >> 3) KASAN_SHADOW_OFFSET = 0xa4e00000 - 0x15e00000 KASAN_SHADOW_OFFSET = 0x8f000000 - The default value of 0xffffffff for KASAN_SHADOW_OFFSET is an error value. We should always match one of the above shadow offsets. When we do this, TASK_SIZE will sometimes get a bit odd values that will not fit into immediate mov assembly instructions. To account for this, we need to rewrite some assembly using TASK_SIZE like this: - mov r1, #TASK_SIZE + ldr r1, =TASK_SIZE or - cmp r4, #TASK_SIZE + ldr r0, =TASK_SIZE + cmp r4, r0 this is done to avoid the immediate #TASK_SIZE that need to fit into a limited number of bits. Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Alexander Potapenko <glider@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: kasan-dev@googlegroups.com Cc: Mike Rapoport <rppt@linux.ibm.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Ard Biesheuvel <ardb@kernel.org> # QEMU/KVM/mach-virt/LPAE/8G Tested-by: Florian Fainelli <f.fainelli@gmail.com> # Brahma SoCs Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # i.MX6Q Reported-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Abbott Liu <liuwenliang@huawei.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-10-27ARM: 9014/2: Replace string mem* functions for KASanLinus Walleij
Functions like memset()/memmove()/memcpy() do a lot of memory accesses. If a bad pointer is passed to one of these functions it is important to catch this. Compiler instrumentation cannot do this since these functions are written in assembly. KASan replaces these memory functions with instrumented variants. The original functions are declared as weak symbols so that the strong definitions in mm/kasan/kasan.c can replace them. The original functions have aliases with a '__' prefix in their name, so we can call the non-instrumented variant if needed. We must use __memcpy()/__memset() in place of memcpy()/memset() when we copy .data to RAM and when we clear .bss, because kasan_early_init cannot be called before the initialization of .data and .bss. For the kernel compression and EFI libstub's custom string libraries we need a special quirk: even if these are built without KASan enabled, they rely on the global headers for their custom string libraries, which means that e.g. memcpy() will be defined to __memcpy() and we get link failures. Since these implementations are written i C rather than assembly we use e.g. __alias(memcpy) to redirected any users back to the local implementation. Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Alexander Potapenko <glider@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: kasan-dev@googlegroups.com Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Ard Biesheuvel <ardb@kernel.org> # QEMU/KVM/mach-virt/LPAE/8G Tested-by: Florian Fainelli <f.fainelli@gmail.com> # Brahma SoCs Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # i.MX6Q Reported-by: Russell King - ARM Linux <rmk+kernel@armlinux.org.uk> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Abbott Liu <liuwenliang@huawei.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-10-27ARM: 9013/2: Disable KASan instrumentation for some codeLinus Walleij
Disable instrumentation for arch/arm/boot/compressed/* since that code is executed before the kernel has even set up its mappings and definately out of scope for KASan. Disable instrumentation of arch/arm/vdso/* because that code is not linked with the kernel image, so the KASan management code would fail to link. Disable instrumentation of arch/arm/mm/physaddr.c. See commit ec6d06efb0ba ("arm64: Add support for CONFIG_DEBUG_VIRTUAL") for more details. Disable kasan check in the function unwind_pop_register because it does not matter that kasan checks failed when unwind_pop_register() reads the stack memory of a task. Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Alexander Potapenko <glider@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: kasan-dev@googlegroups.com Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Ard Biesheuvel <ardb@kernel.org> # QEMU/KVM/mach-virt/LPAE/8G Tested-by: Florian Fainelli <f.fainelli@gmail.com> # Brahma SoCs Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # i.MX6Q Reported-by: Florian Fainelli <f.fainelli@gmail.com> Reported-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Abbott Liu <liuwenliang@huawei.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-10-27ARM: 9012/1: move device tree mapping out of linear regionArd Biesheuvel
On ARM, setting up the linear region is tricky, given the constraints around placement and alignment of the memblocks, and how the kernel itself as well as the DT are placed in physical memory. Let's simplify matters a bit, by moving the device tree mapping to the top of the address space, right between the end of the vmalloc region and the start of the the fixmap region, and create a read-only mapping for it that is independent of the size of the linear region, and how it is organized. Since this region was formerly used as a guard region, which will now be populated fully on LPAE builds by this read-only mapping (which will still be able to function as a guard region for stray writes), bump the start of the [underutilized] fixmap region by 512 KB as well, to ensure that there is always a proper guard region here. Doing so still leaves ample room for the fixmap space, even with NR_CPUS set to its maximum value of 32. Tested-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-10-27ARM: 9011/1: centralize phys-to-virt conversion of DT/ATAGS addressArd Biesheuvel
Before moving the DT mapping out of the linear region, let's prepare for this change by removing all the phys-to-virt translations of the __atags_pointer variable, and perform this translation only once at setup time. Tested-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-10-27Merge tag 'imx-fixes-5.10-2' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes i.MX fixes for 5.10, 2nd round: A couple of more defconfig fixes to enable CONFIG_GPIO_MXC option for i.MX ARMv4/v5 devices. * tag 'imx-fixes-5.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: ARM: multi_v5_defconfig: Select CONFIG_GPIO_MXC ARM: imx_v4_v5_defconfig: Select CONFIG_GPIO_MXC Link: https://lore.kernel.org/r/20201026235230.GL9880@dragon Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-10-27ARM: OMAP2+: Manage MPU state properly for omap_enter_idle_coupled()Tony Lindgren
Based on more testing, commit 8ca5ee624b4c ("ARM: OMAP2+: Restore MPU power domain if cpu_cluster_pm_enter() fails") is a poor fix for handling cpu_cluster_pm_enter() returned errors. We should not override the cpuidle states with a hardcoded PWRDM_POWER_ON value. Instead, we should use a configured idle state that does not cause the context to be lost. Otherwise we end up configuring a potentially improper state for the MPUSS. We also want to update the returned state index for the selected state. Let's just select the highest power idle state C1 to ensure no context loss is allowed on cpu_cluster_pm_enter() errors. With these changes we can now unconditionally call omap4_enter_lowpower() for WFI like we did earlier before commit 55be2f50336f ("ARM: OMAP2+: Handle errors for cpu_pm"). And we can return the selected state index. Fixes: 8f04aea048d5 ("ARM: OMAP2+: Restore MPU power domain if cpu_cluster_pm_enter() fails") Fixes: 55be2f50336f ("ARM: OMAP2+: Handle errors for cpu_pm") Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-10-27ARM: multi_v5_defconfig: Select CONFIG_GPIO_MXCFabio Estevam
Since commit 12d16b397ce0 ("gpio: mxc: Support module build") the CONFIG_GPIO_MXC option needs to be explicitly selected. Select it to avoid boot issues on imx25/imx27 due to the lack of the GPIO driver. Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-10-27ARM: imx_v4_v5_defconfig: Select CONFIG_GPIO_MXCFabio Estevam
Since commit 12d16b397ce0 ("gpio: mxc: Support module build") the CONFIG_GPIO_MXC option needs to be explicitly selected. Select it to avoid boot issues on imx25/imx27 due to the lack of the GPIO driver. Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-10-26ARM: dts: exynos: Remove interrupts from DMC controller in Exynos5422Lukasz Luba
The interrupts in Dynamic Memory Controller in Exynos5422 and Odroid XU3-family boards are no longer needed. They have been used in order to workaround some issues in scheduled work in devfreq. Now when the devfreq framework design is improved, remove the interrupt driven approach and rely on devfreq monitoring mechanism with fixed intervals. Reported-by: Willy Wolff <willy.mh.wolff.ml@gmail.com> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://lore.kernel.org/r/20200708153420.29484-3-lukasz.luba@arm.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2020-10-26ARM: dts: exynos: Harmonize DWC USB3 DT nodes nameSerge Semin
In accordance with the DWC USB3 bindings the corresponding node name is suppose to comply with the Generic USB HCD DT schema, which requires the USB nodes to have the name acceptable by the regexp: "^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly named. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201020115959.2658-20-Sergey.Semin@baikalelectronics.ru Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2020-10-26ARM: dts: exynos: Correct DWC USB3 compatible stringSerge Semin
Syonpsys IP cores are supposed to be defined with "snps" vendor-prefix. Use it instead of the deprecated "synopsys" one. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201020115959.2658-5-Sergey.Semin@baikalelectronics.ru Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2020-10-26ARM: dts: exynos: disable pull up of USB 3.0 over-current on Odroid XUKrzysztof Kozlowski
The Odroid XU has external pull ups for USB 3.0 over-current pins, so disable the internal one. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201015182044.480562-4-krzk@kernel.org Tested-by: Gabriel Ribba Esteva <gabriel.ribbae@gmail.com>
2020-10-26ARM: dts: exynos: fix USB 3.0 pins supply being turned off on Odroid XUKrzysztof Kozlowski
On Odroid XU LDO12 and LDO15 supplies the power to USB 3.0 blocks but the GPK GPIO pins are supplied by LDO7 (VDDQ_LCD). LDO7 also supplies GPJ GPIO pins. The Exynos pinctrl driver does not take any supplies, so to have entire GPIO block always available, make the regulator always on. Fixes: 88644b4c750b ("ARM: dts: exynos: Configure PWM, usb3503, PMIC and thermal on Odroid XU board") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201015182044.480562-3-krzk@kernel.org Tested-by: Gabriel Ribba Esteva <gabriel.ribbae@gmail.com>
2020-10-26ARM: dts: exynos: fix USB 3.0 VBUS control and over-current pins on Exynos5410Krzysztof Kozlowski
The VBUS control (PWREN) and over-current pins of USB 3.0 DWC3 controllers are on Exynos5410 regular GPIOs. This is different than for example on Exynos5422 where these are special ETC pins with proper reset values (pulls, functions). Therefore these pins should be configured to enable proper USB 3.0 peripheral and host modes. This also fixes over-current warning: [ 6.024658] usb usb4-port1: over-current condition [ 6.028271] usb usb3-port1: over-current condition Fixes: cb0896562228 ("ARM: dts: exynos: Add USB to Exynos5410") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201015182044.480562-2-krzk@kernel.org Tested-by: Gabriel Ribba Esteva <gabriel.ribbae@gmail.com>
2020-10-26ARM: dts: exynos: fix roles of USB 3.0 ports on Odroid XUKrzysztof Kozlowski
On Odroid XU board the USB3-0 port is a microUSB and USB3-1 port is USB type A (host). The roles were copied from Odroid XU3 (Exynos5422) design which has it reversed. Fixes: 8149afe4dbf9 ("ARM: dts: exynos: Add initial support for Odroid XU board") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201015182044.480562-1-krzk@kernel.org Tested-by: Gabriel Ribba Esteva <gabriel.ribbae@gmail.com>
2020-10-26ARM: multi_v7_defconfig: enable sound driver for Midas platformMarek Szyprowski
Sound driver for Midas platform (Exnyos4412 SoC based) has been recently merged, so enable it for tests like other sound drivers for Exynos based boards. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20201009134907.4578-1-m.szyprowski@samsung.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2020-10-26ARM: exynos_defconfig: enable sound driver for Midas platformMarek Szyprowski
Sound driver for Midas platform (Exnyos4412 SoC based) has been recently merged, so enable it for tests like other sound drivers for Exynos based boards. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20201009134855.4520-1-m.szyprowski@samsung.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2020-10-26ARM: dts: exynos: Fix schema warnings for pwm-ledsAlexander Dahl
The node names for devices using the pwm-leds driver follow a certain naming scheme (now). Parent node name is not enforced, but recommended by DT project. arch/arm/boot/dts/exynos5410-odroidxu.dt.yaml: pwmleds: 'blueled', 'greenled' do not match any of the regexes: '^led(-[0-9a-f]+)?$', 'pinctrl-[0-9]+' arch/arm/boot/dts/exynos5422-odroidhc1.dt.yaml: pwmleds: 'blueled' does not match any of the regexes: '^led(-[0-9a-f]+)?$', 'pinctrl-[0-9]+' From schema: Documentation/devicetree/bindings/leds/leds-pwm.yaml Signed-off-by: Alexander Dahl <post@lespocky.de> Link: https://lore.kernel.org/r/20201005203451.9985-8-post@lespocky.de Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2020-10-26arm: use asm-generic/mmu_context.h for no-op implementationsNicholas Piggin
Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Cc: Russell King <linux@armlinux.org.uk> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-10-26ARM: dts: qcom: msm8974-klte: Add support for SD cardIskren Chernev
The Samsung Galaxy S5 (klte), has 3 SDHCI nodes used for internal storage, WiFi, external SD card slot. The external SD card slot is similar to the internal storage. Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Link: https://lore.kernel.org/r/20200920144859.813032-8-iskren.chernev@gmail.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-10-26ARM: dts: qcom: msm8974-klte: Add support for wifiIskren Chernev
The Samsung Galaxy S5 (klte), uses a Broadcom 4354 Chip connected on the SDIO bus. The chip also requires a corresponding firmware + txt file[1]. [1] https://gitlab.com/postmarketOS/pmaports/-/blob/master/firmware/firmware-samsung-klte/APKBUILD Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Link: https://lore.kernel.org/r/20200920144859.813032-7-iskren.chernev@gmail.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-10-26ARM: dts: qcom: msm8974-klte: Add gpio expander chipIskren Chernev
The Samsung Galaxy S5 has a GPIO Expander chip, the PCAL6416A with 16 ports on a i2c bus. These pins are used for WiFi, NFC, IR among other things. Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Link: https://lore.kernel.org/r/20200920144859.813032-6-iskren.chernev@gmail.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-10-26ARM: dts: qcom: msm8974-klte: Add support for ledIskren Chernev
The klte uses a Panasonic AN30259A LED controller for it's indicator led. Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Link: https://lore.kernel.org/r/20200920144859.813032-5-iskren.chernev@gmail.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
generated by cgit (git 2.34.1) at 2025-09-19 15:12:54 +0000