aboutsummaryrefslogtreecommitdiff
path: root/arch/arm
AgeCommit message (Collapse)AuthorFilesLines
2020-10-28ARM: dts: aspeed-g6: Fix the GPIO memory sizeBilly Tsai1-1/+1
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 <[email protected]> Reviewed-by: Andrew Jeffery <[email protected]> Reviewed-by: Joel Stanley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joel Stanley <[email protected]>
2020-10-27arm/build: Always handle .ARM.exidx and .ARM.extab sectionsNathan Chancellor1-0/+4
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 <[email protected]> Signed-off-by: Nathan Chancellor <[email protected]> Review-by: Nick Desaulniers <[email protected]> Tested-by: Nick Desaulniers <[email protected]> [kees: Made the discard slightly more specific] Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-27ARM: dts: exynos: Remove 'opp-shared' from Exynos4412 bus OPP-tablesMarek Szyprowski1-6/+0
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]>
2020-10-27ARM: dts: exynos: Remove 'opp-shared' from Exynos3 bus OPP-tablesMarek Szyprowski1-5/+0
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]>
2020-10-27ARM: dts: sun8i: add FriendlyArm ZeroPi supportYu-Tung Chang2-0/+86
The ZeroPi is another fun board developed by FriendlyELEC for makers, hobbyists and fans. ZeroPi key features - Allwinner H3, Quad-core [email protected] - 256MB/512MB DDR3 RAM - microsd slot - 10/100/1000Mbps Ethernet - Debug Serial Port - DC 5V/2A power-supply Signed-off-by: Yu-Tung Chang <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-27ARM: 9019/1: kprobes: Avoid fortify_panic() when copying optprobe templateAndrew Jeffery2-20/+20
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 <[email protected]> Signed-off-by: Andrew Jeffery <[email protected]> Tested-by: Luka Oreskovic <[email protected]> Tested-by: Joel Stanley <[email protected]> Reviewed-by: Joel Stanley <[email protected]> Acked-by: Masami Hiramatsu <[email protected]> Cc: Luka Oreskovic <[email protected]> Cc: Juraj Vijtiuk <[email protected]> Signed-off-by: Russell King <[email protected]>
2020-10-27ARM: 9017/2: Enable KASan for ARMLinus Walleij1-0/+1
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 <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: [email protected] Acked-by: Dmitry Vyukov <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> Tested-by: Ard Biesheuvel <[email protected]> # QEMU/KVM/mach-virt/LPAE/8G Tested-by: Florian Fainelli <[email protected]> # Brahma SoCs Tested-by: Ahmad Fatoum <[email protected]> # i.MX6Q Signed-off-by: Abbott Liu <[email protected]> Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Russell King <[email protected]>
2020-10-27ARM: 9016/2: Initialize the mapping of KASan shadow memoryLinus Walleij8-2/+362
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 <[email protected]> - 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 <[email protected]> Linus Walleij <[email protected]>: - 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 <[email protected]>: - Necessary underlying fixes. - Crucial bug fixes to the memory set-up code. Co-developed-by: Andrey Ryabinin <[email protected]> Co-developed-by: Abbott Liu <[email protected]> Co-developed-by: Ard Biesheuvel <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: [email protected] Cc: Mike Rapoport <[email protected]> Acked-by: Mike Rapoport <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> Tested-by: Ard Biesheuvel <[email protected]> # QEMU/KVM/mach-virt/LPAE/8G Tested-by: Florian Fainelli <[email protected]> # Brahma SoCs Tested-by: Ahmad Fatoum <[email protected]> # i.MX6Q Reported-by: Russell King - ARM Linux <[email protected]> Reported-by: Florian Fainelli <[email protected]> Signed-off-by: Andrey Ryabinin <[email protected]> Signed-off-by: Abbott Liu <[email protected]> Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Russell King <[email protected]>
2020-10-27ARM: 9015/2: Define the virtual space of KASan's shadow regionLinus Walleij7-5/+122
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 <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: [email protected] Cc: Mike Rapoport <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> Tested-by: Ard Biesheuvel <[email protected]> # QEMU/KVM/mach-virt/LPAE/8G Tested-by: Florian Fainelli <[email protected]> # Brahma SoCs Tested-by: Ahmad Fatoum <[email protected]> # i.MX6Q Reported-by: Ard Biesheuvel <[email protected]> Signed-off-by: Abbott Liu <[email protected]> Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Russell King <[email protected]>
2020-10-27ARM: 9014/2: Replace string mem* functions for KASanLinus Walleij6-3/+57
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 <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: [email protected] Reviewed-by: Ard Biesheuvel <[email protected]> Tested-by: Ard Biesheuvel <[email protected]> # QEMU/KVM/mach-virt/LPAE/8G Tested-by: Florian Fainelli <[email protected]> # Brahma SoCs Tested-by: Ahmad Fatoum <[email protected]> # i.MX6Q Reported-by: Russell King - ARM Linux <[email protected]> Signed-off-by: Ahmad Fatoum <[email protected]> Signed-off-by: Abbott Liu <[email protected]> Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Russell King <[email protected]>
2020-10-27ARM: 9013/2: Disable KASan instrumentation for some codeLinus Walleij4-1/+10
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 <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: [email protected] Reviewed-by: Ard Biesheuvel <[email protected]> Tested-by: Ard Biesheuvel <[email protected]> # QEMU/KVM/mach-virt/LPAE/8G Tested-by: Florian Fainelli <[email protected]> # Brahma SoCs Tested-by: Ahmad Fatoum <[email protected]> # i.MX6Q Reported-by: Florian Fainelli <[email protected]> Reported-by: Marc Zyngier <[email protected]> Signed-off-by: Abbott Liu <[email protected]> Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Russell King <[email protected]>
2020-10-27ARM: 9012/1: move device tree mapping out of linear regionArd Biesheuvel7-16/+32
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 <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Reviewed-by: Nicolas Pitre <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Russell King <[email protected]>
2020-10-27ARM: 9011/1: centralize phys-to-virt conversion of DT/ATAGS addressArd Biesheuvel6-17/+21
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 <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Acked-by: Nicolas Pitre <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Russell King <[email protected]>
2020-10-27Merge tag 'imx-fixes-5.10-2' of ↵Arnd Bergmann2-0/+2
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 <[email protected]>
2020-10-27ARM: OMAP2+: Manage MPU state properly for omap_enter_idle_coupled()Tony Lindgren1-3/+5
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 <[email protected]>
2020-10-27ARM: multi_v5_defconfig: Select CONFIG_GPIO_MXCFabio Estevam1-0/+1
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 <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-10-27ARM: imx_v4_v5_defconfig: Select CONFIG_GPIO_MXCFabio Estevam1-0/+1
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 <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-10-26ARM: dts: exynos: Remove interrupts from DMC controller in Exynos5422Lukasz Luba1-3/+0
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 <[email protected]> Signed-off-by: Lukasz Luba <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]>
2020-10-26ARM: dts: exynos: Harmonize DWC USB3 DT nodes nameSerge Semin2-3/+3
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]>
2020-10-26ARM: dts: exynos: Correct DWC USB3 compatible stringSerge Semin1-1/+1
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]>
2020-10-26ARM: dts: exynos: disable pull up of USB 3.0 over-current on Odroid XUKrzysztof Kozlowski1-0/+10
The Odroid XU has external pull ups for USB 3.0 over-current pins, so disable the internal one. Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Gabriel Ribba Esteva <[email protected]>
2020-10-26ARM: dts: exynos: fix USB 3.0 pins supply being turned off on Odroid XUKrzysztof Kozlowski1-0/+2
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 <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Gabriel Ribba Esteva <[email protected]>
2020-10-26ARM: dts: exynos: fix USB 3.0 VBUS control and over-current pins on Exynos5410Krzysztof Kozlowski2-0/+32
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 <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Gabriel Ribba Esteva <[email protected]>
2020-10-26ARM: dts: exynos: fix roles of USB 3.0 ports on Odroid XUKrzysztof Kozlowski1-2/+2
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 <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Gabriel Ribba Esteva <[email protected]>
2020-10-26ARM: multi_v7_defconfig: enable sound driver for Midas platformMarek Szyprowski1-0/+1
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]>
2020-10-26ARM: exynos_defconfig: enable sound driver for Midas platformMarek Szyprowski1-0/+1
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]>
2020-10-26ARM: dts: exynos: Fix schema warnings for pwm-ledsAlexander Dahl3-9/+10
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]>
2020-10-26arm: use asm-generic/mmu_context.h for no-op implementationsNicholas Piggin1-23/+3
Signed-off-by: Nicholas Piggin <[email protected]> Cc: Russell King <[email protected]> Cc: [email protected] Signed-off-by: Arnd Bergmann <[email protected]>
2020-10-26ARM: dts: qcom: msm8974-klte: Add support for SD cardIskren Chernev1-1/+43
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-10-26ARM: dts: qcom: msm8974-klte: Add support for wifiIskren Chernev1-0/+74
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-10-26ARM: dts: qcom: msm8974-klte: Add gpio expander chipIskren Chernev1-2/+27
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-10-26ARM: dts: qcom: msm8974-klte: Add support for ledIskren Chernev1-0/+48
The klte uses a Panasonic AN30259A LED controller for it's indicator led. Signed-off-by: Iskren Chernev <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-10-26ARM: dts: qcom: msm8974-klte: Add support for touchscreenIskren Chernev1-0/+54
Add support for the touchscreen found on the Samsung Galaxy S5. Signed-off-by: Iskren Chernev <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-10-26ARM: dts: qcom: msm8974-klte: Add support for touchkeyIskren Chernev1-1/+43
Add support for the touchkey found on the Samsung Galaxy S5. The touchkey is responsible for handling the application and back buttons found around the home button. Signed-off-by: Iskren Chernev <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-10-26ARM: dts: qcom: msm8974-klte: Merge pinctrl nodesIskren Chernev1-12/+10
commit cd13c72c1853f219e1f ("ARM: dts: qcom: msm8974-klte: Add max77826 pmic node") and commit 8bf7a360a92cc6b2aebc8 ("ARM: dts: qcom: msm8974-klte: Add sdhci1 node") both added pinctrl node. This patch merges the two nodes. Signed-off-by: Iskren Chernev <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2020-10-26Merge tag 'imx-fixes-5.10' of ↵Arnd Bergmann2-0/+2
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes i.MX fixes for 5.10: With commit 12d16b397ce0 ("gpio: mxc: Support module build") in place, GPIO_MXC has no 'def_bool y' anymore, and needs to be enabled by defconfig. It updates the defconfig files to explicitly enable the option for fixing boot failure on i.MX platform. * tag 'imx-fixes-5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: ARM: multi_v7_defconfig: Build in CONFIG_GPIO_MXC by default ARM: imx_v6_v7_defconfig: Build in CONFIG_GPIO_MXC by default arm64: defconfig: Build in CONFIG_GPIO_MXC by default Link: https://lore.kernel.org/r/20201026135601.GA32675@dragon Signed-off-by: Arnd Bergmann <[email protected]>
2020-10-26ARM: dts: sunxi: bananapi-m2-plus: Enable RGMII RX/TX delay on Ethernet PHYChen-Yu Tsai1-1/+1
The Ethernet PHY on the Bananapi M2+ has the RX and TX delays enabled on the PHY, using pull-ups on the RXDLY and TXDLY pins. Fix the phy-mode description to correct reflect this so that the implementation doesn't reconfigure the delays incorrectly. This happened with commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config"). Fixes: 8c7ba536e709 ("ARM: sun8i: bananapi-m2-plus: Enable dwmac-sun8i") Fixes: 4904337fe34f ("ARM: dts: sunxi: Restore EMAC changes (boards)") Fixes: aa8fee415f46 ("ARM: dts: sun8i: h3: Split out non-SoC-specific parts of Bananapi M2 Plus") Signed-off-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Tested-by: Jernej Skrabec <[email protected]> Acked-by: Jernej Skrabec <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-26ARM: dts: sun9i: Enable both RGMII RX/TX delay on Ethernet PHYChen-Yu Tsai2-2/+2
The Ethernet PHY on the Cubieboard 4 and A80 Optimus have the RX and TX delays enabled on the PHY, using pull-ups on the RXDLY and TXDLY pins. Fix the phy-mode description to correct reflect this so that the implementation doesn't reconfigure the delays incorrectly. This happened with commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config"). Fixes: 98048143b7f8 ("ARM: dts: sun9i: cubieboard4: Enable GMAC") Fixes: bc9bd03a44f9 ("ARM: dts: sun9i: a80-optimus: Enable GMAC") Signed-off-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Acked-by: Jernej Skrabec <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-26ARM: dts: sun8i: a83t: Enable both RGMII RX/TX delay on Ethernet PHYChen-Yu Tsai2-2/+2
The Ethernet PHY on the Bananapi M3 and Cubietruck Plus have the RX and TX delays enabled on the PHY, using pull-ups on the RXDLY and TXDLY pins. Fix the phy-mode description to correct reflect this so that the implementation doesn't reconfigure the delays incorrectly. This happened with commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config"). Fixes: 039359948a4b ("ARM: dts: sun8i: a83t: Enable Ethernet on two boards") Signed-off-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Acked-by: Jernej Skrabec <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-26ARM: dts: sun8i: h3: orangepi-plus2e: Enable RGMII RX/TX delay on Ethernet PHYChen-Yu Tsai1-1/+1
The Ethernet PHY on the Orange Pi Plus 2E has the RX and TX delays enabled on the PHY, using pull-ups on the RXDLY and TXDLY pins. Fix the phy-mode description to correct reflect this so that the implementation doesn't reconfigure the delays incorrectly. This happened with commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config"). Fixes: 4904337fe34f ("ARM: dts: sunxi: Restore EMAC changes (boards)") Fixes: 7a78ef92cdc5 ("ARM: sun8i: h3: Enable EMAC with external PHY on Orange Pi Plus 2E") Signed-off-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Tested-by: Jernej Skrabec <[email protected]> Acked-by: Jernej Skrabec <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-26ARM: dts: sun7i: bananapi-m1-plus: Enable RGMII RX/TX delay on Ethernet PHYChen-Yu Tsai1-1/+1
The Ethernet PHY on the Bananapi M1+ has the RX and TX delays enabled on the PHY, using pull-ups on the RXDLY and TXDLY pins. Fix the phy-mode description to correct reflect this so that the implementation doesn't reconfigure the delays incorrectly. This happened with commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config"). Fixes: 04c85ecad32a ("ARM: dts: sun7i: Add dts file for Bananapi M1 Plus board") Signed-off-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Acked-by: Jernej Skrabec <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-26ARM: dts: sun7i: cubietruck: Enable RGMII RX/TX delay on Ethernet PHYChen-Yu Tsai1-1/+1
The Ethernet PHY on the Cubietruck has the RX and TX delays enabled on the PHY, using pull-ups on the RXDLY and TXDLY pins. Fix the phy-mode description to correct reflect this so that the implementation doesn't reconfigure the delays incorrectly. This happened with commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config"). Fixes: 67073d97672d ("ARM: dts: sun7i: cubietruck: Enable the GMAC") Signed-off-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Tested-by: Emilio López <[email protected]> Reviewed-by: Emilio López <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-26ARM: dts: sun6i: a31-hummingbird: Enable RGMII RX/TX delay on Ethernet PHYChen-Yu Tsai1-1/+1
The Ethernet PHY on the A31 Hummingbird has the RX and TX delays enabled on the PHY, using pull-ups on the RXDLY and TXDLY pins. Fix the phy-mode description to correct reflect this so that the implementation doesn't reconfigure the delays incorrectly. This happened with commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config"). Fixes: c220aec2bb79 ("ARM: dts: sun6i: Add Merrii A31 Hummingbird support") Signed-off-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Acked-by: Jernej Skrabec <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-26Revert "arm: sun8i: orangepi-pc-plus: Set EMAC activity LEDs to active high"Chen-Yu Tsai1-5/+0
This reverts commit 75ee680cbd2e4d0156b94f9fec50076361ab12f2. Turns out the activity and link LEDs on the RJ45 port are active low, just like on the Orange Pi PC. Revert the commit that says otherwise. Fixes: 75ee680cbd2e ("arm: sun8i: orangepi-pc-plus: Set EMAC activity LEDs to active high") Fixes: 4904337fe34f ("ARM: dts: sunxi: Restore EMAC changes (boards)") Signed-off-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Tested-by: Jernej Skrabec <[email protected]> Acked-by: Jernej Skrabec <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-26ARM: dts: sun8i: r40: bananapi-m2-ultra: Fix ethernet nodeJernej Skrabec1-1/+1
Ethernet PHY on BananaPi M2 Ultra provides RX and TX delays. Fix ethernet node to reflect that fact. Fixes: c36fd5a48bd2 ("ARM: dts: sun8i: r40: bananapi-m2-ultra: Enable GMAC ethernet controller") Signed-off-by: Jernej Skrabec <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-26ARM: dts: mmp2-olpc-xo-1-75: Use plural form of "-gpios"Lubomir Rintel1-2/+2
This makes validation happier. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lubomir Rintel <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2020-10-26ARM: dts: mmp3: Add power domain for the cameraLubomir Rintel1-0/+2
The camera interfaces on MMP3 are on a separate power island that needs to be turned on for them to operate and, ideally, turned off when the cameras are not in use. This hooks the power island with the camera interfaces in the device tree. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lubomir Rintel <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2020-10-26Merge tag 'sunxi-fixes-for-5.9-2' of ↵Arnd Bergmann1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into arm/fixes One fix for an unreasonable thermal trip point on the A10 * tag 'sunxi-fixes-for-5.9-2' of git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux: ARM: dts: sun4i-a10: fix cpu_alert temperature Link: https://lore.kernel.org/r/3c95a95f-c6fa-4b34-823b-ddaa7660d274.lettre@localhost Signed-off-by: Arnd Bergmann <[email protected]>
2020-10-26Merge tag 'mvebu-fixes-5.9-1' of ↵Arnd Bergmann1-6/+1
git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu into arm/fixes mvebu fixes for 5.9 (part 1) - Allow to use correct MAC address for particular DSA slaves / ethernet ports on Espressobin (Armada 3720) - Remove incorrect check in ll_get_coherency_base() used for Armada 370/XP SoCs. * tag 'mvebu-fixes-5.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu: ARM: mvebu: drop pointless check for coherency_base arm64: dts: marvell: espressobin: Add ethernet switch aliases Link: https://lore.kernel.org/r/87y2kkesj5.fsf@BL-laptop Signed-off-by: Arnd Bergmann <[email protected]>
2020-10-26ARM: dts: r8a7742-iwg21d-q7-dbcm-ca: Enable VIN instancesLad Prabhakar1-0/+222
Enable VIN instances along with OV5640 as endpoints on the adapter board. Signed-off-by: Lad Prabhakar <[email protected]> Reviewed-by: Biju Das <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>