summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2024-08-28arm64: dts: ti: iot2050: Add overlays for M.2 used by firmwareJan Kiszka3-0/+80
To allow firmware to pick up all DTs from here, move the overlays that are normally applied during DT fixup to the kernel source as well. Hook then into the build nevertheless to ensure that regular checks are performed. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Link: https://lore.kernel.org/r/91f8b825467651ebd51a4051f153ab136eeb1849.1724830741.git.jan.kiszka@siemens.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-08-28arm64: dts: ti: iot2050: Disable lock-step for all iot2050 boardsLi Hua Qian3-10/+5
The PG1 A variant of the iot2050 series has been identified which partially lacks support for lock-step mode. This implies that all iot2050 boards can't support this mode. As a result, lock-step mode has been disabled across all iot2050 boards for consistency and to avoid potential issues. Signed-off-by: Li Hua Qian <huaqian.li@siemens.com> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Link: https://lore.kernel.org/r/d1f5f84db7a1597cd29628a0b503e578367b7b40.1724830741.git.jan.kiszka@siemens.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-08-28arm64: dts: ti: k3-am69-sk: Switch MAIN R5F clusters to Split-modeBeleswar Padhi1-0/+12
The TI AM69 SK board has three R5F clusters in the MAIN domain, and all of these are configured for LockStep mode at the moment. Switch all of these R5F clusters to Split mode by default to maximize the number of R5F cores. Signed-off-by: Beleswar Padhi <b-padhi@ti.com> Link: https://lore.kernel.org/r/20240826093024.1183540-8-b-padhi@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-08-28arm64: dts: ti: k3-j784s4-evm: Switch MAIN R5F clusters to Split-modeBeleswar Padhi1-0/+12
The TI J784S4 EVM board has three R5F clusters in the MAIN domain, and all of these are configured for LockStep mode at the moment. Switch all of these R5F clusters to Split mode by default to maximize the number of R5F cores. Signed-off-by: Beleswar Padhi <b-padhi@ti.com> Link: https://lore.kernel.org/r/20240826093024.1183540-7-b-padhi@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-08-28arm64: dts: ti: k3-am68-sk-som: Switch MAIN R5F clusters to Split-modeBeleswar Padhi1-0/+8
The TI AM68 SK board has two R5F clusters in the MAIN domain, and both of these are configured for LockStep mode at the moment. Switch both of these R5F clusters to Split mode by default to maximize the number of R5F cores. Signed-off-by: Beleswar Padhi <b-padhi@ti.com> Link: https://lore.kernel.org/r/20240826093024.1183540-6-b-padhi@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-08-28arm64: dts: ti: k3-j721s2-som-p0: Switch MAIN R5F clusters to Split-modeBeleswar Padhi1-0/+8
The TI J721S2 EVM board has two R5F clusters in the MAIN domain, and both of these are configured for LockStep mode at the moment. Switch both of these R5F clusters to Split mode by default to maximize the number of R5F cores. Signed-off-by: Beleswar Padhi <b-padhi@ti.com> Link: https://lore.kernel.org/r/20240826093024.1183540-5-b-padhi@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-08-28arm64: dts: ti: k3-j721e-sk: Switch MAIN R5F clusters to Split-modeBeleswar Padhi1-0/+8
The TI J721E SK board has two R5F clusters in the MAIN domain, and both of these are configured for LockStep mode at the moment. Switch both of these R5F clusters to Split mode by default to maximize the number of R5F cores. Signed-off-by: Beleswar Padhi <b-padhi@ti.com> Link: https://lore.kernel.org/r/20240826093024.1183540-4-b-padhi@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-08-28arm64: dts: ti: k3-j721e-som-p0: Switch MAIN R5F clusters to Split-modeBeleswar Padhi1-0/+8
The TI J721E EVM board has two R5F clusters in the MAIN domain, and both of these are configured for LockStep mode at the moment. Switch both of these R5F clusters to Split mode by default to maximize the number of R5F cores. Signed-off-by: Beleswar Padhi <b-padhi@ti.com> Link: https://lore.kernel.org/r/20240826093024.1183540-3-b-padhi@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-08-28arm64: dts: ti: k3-j7200-som-p0: Switch MAIN R5F cluster to Split-modeBeleswar Padhi1-0/+4
The TI J7200 EVM board has one R5F cluster in the MAIN domain, and it is configured for LockStep mode at the moment. Switch the MAIN R5F cluster to Split mode by default to maximize the number of R5F cores. Signed-off-by: Beleswar Padhi <b-padhi@ti.com> Link: https://lore.kernel.org/r/20240826093024.1183540-2-b-padhi@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-08-28arm64: defconfig: Enable E5010 JPEG EncoderDevarsh Thakkar1-0/+1
This enables E5010 JPEG Encoder which is a stateful JPEG Encoder present in TI's AM62A SoC [1] and supporting baseline encoding of semiplanar based YUV420 and YUV422 raw video formats to JPEG encoding, with resolutions supported from 64x64 to 8kx8k resolution. Link: https://www.ti.com/lit/pdf/spruj16 [1] Signed-off-by: Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20240826162250.380005-3-devarsht@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-08-28arm64: dts: ti: k3-am64*: Disable ethernet by default at SoC levelLogan Bristol6-12/+15
External interfaces should be disabled at the SoC DTSI level, since the node is incomplete. Disable Ethernet switch and ports in SoC DTSI and enable them in the board DTS. If the board DTS includes a SoM DTSI that completes the node description, enable the Ethernet switch and ports in SoM DTSI. Reflect this change in SoM DTSIs by removing ethernet port disable. Signed-off-by: Logan Bristol <logan.bristol@utexas.edu> Acked-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Acked-by: Josua Mayer <josua@solid-run.com> Link: https://lore.kernel.org/r/20240809135753.1186-1-logan.bristol@utexas.edu Signed-off-by: Nishanth Menon <nm@ti.com>
2024-08-28arm64: dts: ti: k3-j784s4-main: Align watchdog clocksEric Chanudet1-19/+19
assigned-clock sets DEV_RTIx_RTI_CLK(id:0) whereas clocks sets DEV_RTIx_RTI_CLK_PARENT_GLUELOGIC_HFOSC0_CLKOUT(id:1)[1]. This does not look right, the timers in the driver assume a max frequency of 32kHz for the heartbeat (HFOSC0 is 19.2MHz on j784s4-evm). With this change, WDIOC_GETTIMELEFT return coherent time left (DEFAULT_HEARTBEAT=60, reports 60s upon opening the cdev). [1] https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j784s4/clocks.html#clocks-for-rti0-device Fixes: caae599de8c6 ("arm64: dts: ti: k3-j784s4-main: Add the main domain watchdog instances") Suggested-by: Andrew Halaney <ahalaney@redhat.com> Signed-off-by: Eric Chanudet <echanude@redhat.com> Tested-by: Andrew Halaney <ahalaney@redhat.com> Tested-by: Udit Kumar <u-kumar1@ti.com> Link: https://lore.kernel.org/r/20240805174330.2132717-2-echanude@redhat.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-08-28arm64: dts: ti: k3-j721e-beagleboneai64: Fix reversed C6x carveout locationsAndrew Davis1-2/+2
The DMA carveout for the C6x core 0 is at 0xa6000000 and core 1 is at 0xa7000000. These are reversed in DT. While both C6x can access either region, so this is not normally a problem, but if we start restricting the memory each core can access (such as with firewalls) the cores accessing the regions for the wrong core will not work. Fix this here. Fixes: fae14a1cb8dd ("arm64: dts: ti: Add k3-j721e-beagleboneai64") Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240801181232.55027-2-afd@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-08-28arm64: dts: ti: k3-j721e-sk: Fix reversed C6x carveout locationsAndrew Davis1-2/+2
The DMA carveout for the C6x core 0 is at 0xa6000000 and core 1 is at 0xa7000000. These are reversed in DT. While both C6x can access either region, so this is not normally a problem, but if we start restricting the memory each core can access (such as with firewalls) the cores accessing the regions for the wrong core will not work. Fix this here. Fixes: f46d16cf5b43 ("arm64: dts: ti: k3-j721e-sk: Add DDR carveout memory nodes") Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240801181232.55027-1-afd@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-08-28bpf, arm64: Avoid blindly saving/restoring all callee-saved registersXu Kuohai1-111/+183
The arm64 jit blindly saves/restores all callee-saved registers, making the jited result looks a bit too compliated. For example, for an empty prog, the jited result is: 0: bti jc 4: mov x9, lr 8: nop c: paciasp 10: stp fp, lr, [sp, #-16]! 14: mov fp, sp 18: stp x19, x20, [sp, #-16]! 1c: stp x21, x22, [sp, #-16]! 20: stp x26, x25, [sp, #-16]! 24: mov x26, #0 28: stp x26, x25, [sp, #-16]! 2c: mov x26, sp 30: stp x27, x28, [sp, #-16]! 34: mov x25, sp 38: bti j // tailcall target 3c: sub sp, sp, #0 40: mov x7, #0 44: add sp, sp, #0 48: ldp x27, x28, [sp], #16 4c: ldp x26, x25, [sp], #16 50: ldp x26, x25, [sp], #16 54: ldp x21, x22, [sp], #16 58: ldp x19, x20, [sp], #16 5c: ldp fp, lr, [sp], #16 60: mov x0, x7 64: autiasp 68: ret Clearly, there is no need to save/restore unused callee-saved registers. This patch does this change, making the jited image to only save/restore the callee-saved registers it uses. Now the jited result of empty prog is: 0: bti jc 4: mov x9, lr 8: nop c: paciasp 10: stp fp, lr, [sp, #-16]! 14: mov fp, sp 18: stp xzr, x26, [sp, #-16]! 1c: mov x26, sp 20: bti j // tailcall target 24: mov x7, #0 28: ldp xzr, x26, [sp], #16 2c: ldp fp, lr, [sp], #16 30: mov x0, x7 34: autiasp 38: ret Since bpf prog saves/restores its own callee-saved registers as needed, to make tailcall work correctly, the caller needs to restore its saved registers before tailcall, and the callee needs to save its callee-saved registers after tailcall. This extra restoring/saving instructions increases preformance overhead. [1] provides 2 benchmarks for tailcall scenarios. Below is the perf number measured in an arm64 KVM guest. The result indicates that the performance difference before and after the patch in typical tailcall scenarios is negligible. - Before: Performance counter stats for './test_progs -t tailcalls' (5 runs): 4313.43 msec task-clock # 0.874 CPUs utilized ( +- 0.16% ) 574 context-switches # 133.073 /sec ( +- 1.14% ) 0 cpu-migrations # 0.000 /sec 538 page-faults # 124.727 /sec ( +- 0.57% ) 10697772784 cycles # 2.480 GHz ( +- 0.22% ) (61.19%) 25511241955 instructions # 2.38 insn per cycle ( +- 0.08% ) (66.70%) 5108910557 branches # 1.184 G/sec ( +- 0.08% ) (72.38%) 2800459 branch-misses # 0.05% of all branches ( +- 0.51% ) (72.36%) TopDownL1 # 0.60 retiring ( +- 0.09% ) (66.84%) # 0.21 frontend_bound ( +- 0.15% ) (61.31%) # 0.12 bad_speculation ( +- 0.08% ) (50.11%) # 0.07 backend_bound ( +- 0.16% ) (33.30%) 8274201819 L1-dcache-loads # 1.918 G/sec ( +- 0.18% ) (33.15%) 468268 L1-dcache-load-misses # 0.01% of all L1-dcache accesses ( +- 4.69% ) (33.16%) 385383 LLC-loads # 89.345 K/sec ( +- 5.22% ) (33.16%) 38296 LLC-load-misses # 9.94% of all LL-cache accesses ( +- 42.52% ) (38.69%) 6886576501 L1-icache-loads # 1.597 G/sec ( +- 0.35% ) (38.69%) 1848585 L1-icache-load-misses # 0.03% of all L1-icache accesses ( +- 4.52% ) (44.23%) 9043645883 dTLB-loads # 2.097 G/sec ( +- 0.10% ) (44.33%) 416672 dTLB-load-misses # 0.00% of all dTLB cache accesses ( +- 5.15% ) (49.89%) 6925626111 iTLB-loads # 1.606 G/sec ( +- 0.35% ) (55.46%) 66220 iTLB-load-misses # 0.00% of all iTLB cache accesses ( +- 1.88% ) (55.50%) <not supported> L1-dcache-prefetches <not supported> L1-dcache-prefetch-misses 4.9372 +- 0.0526 seconds time elapsed ( +- 1.07% ) Performance counter stats for './test_progs -t flow_dissector' (5 runs): 10924.50 msec task-clock # 0.945 CPUs utilized ( +- 0.08% ) 603 context-switches # 55.197 /sec ( +- 1.13% ) 0 cpu-migrations # 0.000 /sec 566 page-faults # 51.810 /sec ( +- 0.42% ) 27381270695 cycles # 2.506 GHz ( +- 0.18% ) (60.46%) 56996583922 instructions # 2.08 insn per cycle ( +- 0.21% ) (66.11%) 10321647567 branches # 944.816 M/sec ( +- 0.17% ) (71.79%) 3347735 branch-misses # 0.03% of all branches ( +- 3.72% ) (72.15%) TopDownL1 # 0.52 retiring ( +- 0.13% ) (66.74%) # 0.27 frontend_bound ( +- 0.14% ) (61.27%) # 0.14 bad_speculation ( +- 0.19% ) (50.36%) # 0.07 backend_bound ( +- 0.42% ) (33.89%) 18740797617 L1-dcache-loads # 1.715 G/sec ( +- 0.43% ) (33.71%) 13715669 L1-dcache-load-misses # 0.07% of all L1-dcache accesses ( +- 32.85% ) (33.34%) 4087551 LLC-loads # 374.164 K/sec ( +- 29.53% ) (33.26%) 267906 LLC-load-misses # 6.55% of all LL-cache accesses ( +- 23.90% ) (38.76%) 15811864229 L1-icache-loads # 1.447 G/sec ( +- 0.12% ) (38.73%) 2976833 L1-icache-load-misses # 0.02% of all L1-icache accesses ( +- 9.73% ) (44.22%) 20138907471 dTLB-loads # 1.843 G/sec ( +- 0.18% ) (44.15%) 732850 dTLB-load-misses # 0.00% of all dTLB cache accesses ( +- 11.18% ) (49.64%) 15895726702 iTLB-loads # 1.455 G/sec ( +- 0.15% ) (55.13%) 152075 iTLB-load-misses # 0.00% of all iTLB cache accesses ( +- 4.71% ) (54.98%) <not supported> L1-dcache-prefetches <not supported> L1-dcache-prefetch-misses 11.5613 +- 0.0317 seconds time elapsed ( +- 0.27% ) - After: Performance counter stats for './test_progs -t tailcalls' (5 runs): 4278.78 msec task-clock # 0.871 CPUs utilized ( +- 0.15% ) 569 context-switches # 132.982 /sec ( +- 0.58% ) 0 cpu-migrations # 0.000 /sec 539 page-faults # 125.970 /sec ( +- 0.43% ) 10588986432 cycles # 2.475 GHz ( +- 0.20% ) (60.91%) 25303825043 instructions # 2.39 insn per cycle ( +- 0.08% ) (66.48%) 5110756256 branches # 1.194 G/sec ( +- 0.07% ) (72.03%) 2719569 branch-misses # 0.05% of all branches ( +- 2.42% ) (72.03%) TopDownL1 # 0.60 retiring ( +- 0.22% ) (66.31%) # 0.22 frontend_bound ( +- 0.21% ) (60.83%) # 0.12 bad_speculation ( +- 0.26% ) (50.25%) # 0.06 backend_bound ( +- 0.17% ) (33.52%) 8163648527 L1-dcache-loads # 1.908 G/sec ( +- 0.33% ) (33.52%) 694979 L1-dcache-load-misses # 0.01% of all L1-dcache accesses ( +- 30.53% ) (33.52%) 1902347 LLC-loads # 444.600 K/sec ( +- 48.84% ) (33.69%) 96677 LLC-load-misses # 5.08% of all LL-cache accesses ( +- 43.48% ) (39.30%) 6863517589 L1-icache-loads # 1.604 G/sec ( +- 0.37% ) (39.17%) 1871519 L1-icache-load-misses # 0.03% of all L1-icache accesses ( +- 6.78% ) (44.56%) 8927782813 dTLB-loads # 2.087 G/sec ( +- 0.14% ) (44.37%) 438237 dTLB-load-misses # 0.00% of all dTLB cache accesses ( +- 6.00% ) (49.75%) 6886906831 iTLB-loads # 1.610 G/sec ( +- 0.36% ) (55.08%) 67568 iTLB-load-misses # 0.00% of all iTLB cache accesses ( +- 3.27% ) (54.86%) <not supported> L1-dcache-prefetches <not supported> L1-dcache-prefetch-misses 4.9114 +- 0.0309 seconds time elapsed ( +- 0.63% ) Performance counter stats for './test_progs -t flow_dissector' (5 runs): 10948.40 msec task-clock # 0.942 CPUs utilized ( +- 0.05% ) 615 context-switches # 56.173 /sec ( +- 1.65% ) 1 cpu-migrations # 0.091 /sec ( +- 31.62% ) 567 page-faults # 51.788 /sec ( +- 0.44% ) 27334194328 cycles # 2.497 GHz ( +- 0.08% ) (61.05%) 56656528828 instructions # 2.07 insn per cycle ( +- 0.08% ) (66.67%) 10270389422 branches # 938.072 M/sec ( +- 0.10% ) (72.21%) 3453837 branch-misses # 0.03% of all branches ( +- 3.75% ) (72.27%) TopDownL1 # 0.52 retiring ( +- 0.16% ) (66.55%) # 0.27 frontend_bound ( +- 0.09% ) (60.91%) # 0.14 bad_speculation ( +- 0.08% ) (49.85%) # 0.07 backend_bound ( +- 0.16% ) (33.33%) 18982866028 L1-dcache-loads # 1.734 G/sec ( +- 0.24% ) (33.34%) 8802454 L1-dcache-load-misses # 0.05% of all L1-dcache accesses ( +- 52.30% ) (33.31%) 2612962 LLC-loads # 238.661 K/sec ( +- 29.78% ) (33.45%) 264107 LLC-load-misses # 10.11% of all LL-cache accesses ( +- 18.34% ) (39.07%) 15793205997 L1-icache-loads # 1.443 G/sec ( +- 0.15% ) (39.09%) 3930802 L1-icache-load-misses # 0.02% of all L1-icache accesses ( +- 3.72% ) (44.66%) 20097828496 dTLB-loads # 1.836 G/sec ( +- 0.09% ) (44.68%) 961757 dTLB-load-misses # 0.00% of all dTLB cache accesses ( +- 3.32% ) (50.15%) 15838728506 iTLB-loads # 1.447 G/sec ( +- 0.09% ) (55.62%) 167652 iTLB-load-misses # 0.00% of all iTLB cache accesses ( +- 1.28% ) (55.52%) <not supported> L1-dcache-prefetches <not supported> L1-dcache-prefetch-misses 11.6173 +- 0.0268 seconds time elapsed ( +- 0.23% ) [1] https://lore.kernel.org/bpf/20200724123644.5096-1-maciej.fijalkowski@intel.com/ Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Link: https://lore.kernel.org/r/20240826071624.350108-3-xukuohai@huaweicloud.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-08-28bpf, arm64: Get rid of fpbXu Kuohai1-93/+11
bpf prog accesses stack using BPF_FP as the base address and a negative immediate number as offset. But arm64 ldr/str instructions only support non-negative immediate number as offset. To simplify the jited result, commit 5b3d19b9bd40 ("bpf, arm64: Adjust the offset of str/ldr(immediate) to positive number") introduced FPB to represent the lowest stack address that the bpf prog being jited may access, and with this address as the baseline, it converts BPF_FP plus negative immediate offset number to FPB plus non-negative immediate offset. Considering that for a given bpf prog, the jited stack space is fixed with A64_SP as the lowest address and BPF_FP as the highest address. Thus we can get rid of FPB and converts BPF_FP plus negative immediate offset to A64_SP plus non-negative immediate offset. Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Link: https://lore.kernel.org/r/20240826071624.350108-2-xukuohai@huaweicloud.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-08-28arm64: dts: rockchip: disable display subsystem only for Radxa E25Chukun Pan2-4/+4
The SoM board has reserved HDMI output, while the Radxa E25 is not connected. So disable the display subsystem only for Radxa E25. Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/20240820120020.469375-1-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-08-28arm64: dts: rockchip: enable PCIe on M.2 E key for Radxa ROCK 5AFUKAUMI Naoki1-0/+30
Enable pcie2x1l2 and related combphy/regulator routed to M.2 E key connector on Radxa ROCK 5A. Tested with Radxa Wireless Module A8: $ lspci 0004:40:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3588 (rev 01) 0004:41:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8852BE PCIe 802.11ax Wireless Network Controller $ ip l 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether c2:58:fc:70:55:86 brd ff:ff:ff:ff:ff:ff 3: wlP4p65s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 2c:05:47:65:5b:ed brd ff:ff:ff:ff:ff:ff $ lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub Bus 001 Device 003: ID 0bda:b85b Realtek Semiconductor Corp. Bluetooth Radio Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 006 Device 002: ID 0789:0336 Logitec Corp. LMD USB Device Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub $ hciconfig hci0: Type: Primary Bus: USB BD Address: 2C:05:47:65:5B:EE ACL MTU: 1021:6 SCO MTU: 255:12 UP RUNNING RX bytes:2698 acl:0 sco:0 events:329 errors:0 TX bytes:69393 acl:0 sco:0 commands:329 errors:0 Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> Link: https://lore.kernel.org/r/20240826080456.525-1-naoki@radxa.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-08-28arm64: dts: rockchip: remove unnecessary properties for Radxa ROCK 5AFUKAUMI Naoki1-24/+0
There is no "on-board WLAN/BT chip" on Radxa ROCK 5A. remove related properties. Fixes: 1642bf66e270 ("arm64: dts: rockchip: add USB2 to rk3588s-rock5a") Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> Link: https://lore.kernel.org/r/20240826075130.546-1-naoki@radxa.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-08-28arm64: dts: rockchip: add dts for LCKFB Taishan Pi RK3566Junhao Xie2-0/+726
Add dts for LCKFB Taishan Pi. Working IO: * UART * RGB LED * AP6212 WiFi * AP6212 Bluetooth * SD Card * eMMC * HDMI * USB Type-C * USB Type-A Signed-off-by: Junhao Xie <bigfoot@classfun.cn> Link: https://lore.kernel.org/r/20240826110300.735350-1-bigfoot@classfun.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-08-28arm64: dts: rockchip: Add Hardkernel ODROID-M1SJonas Karlman2-0/+664
The Hardkernel ODROID-M1S is a single-board computer based on Rockchip RK3566 SoC. It features e.g. 4/8 GB LPDDR4 RAM, 64 GB eMMC, SD-card, GbE LAN, HDMI 2.0, M.2 NVMe and USB 2.0/3.0. Add initial support for eMMC, SD-card, Ethernet, HDMI, PCIe and USB. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Link: https://lore.kernel.org/r/20240827211825.1419820-5-jonas@kwiboo.se Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-08-28arm64: dts: rockchip: Correct vendor prefix for Hardkernel ODROID-M1Jonas Karlman1-1/+1
The vendor prefix for Hardkernel ODROID-M1 is incorrectly listed as rockchip. Use the proper hardkernel vendor prefix for this board, while at it also drop the redundant soc prefix. Fixes: fd3583267703 ("arm64: dts: rockchip: Add Hardkernel ODROID-M1 board") Reviewed-by: Aurelien Jarno <aurelien@aurel32.net> Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Link: https://lore.kernel.org/r/20240827211825.1419820-3-jonas@kwiboo.se Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-08-28arm64: dts: rockchip: Enable RK809 audio codec for Radxa ROCK 4C+Jonathan Liu1-1/+45
This adds the necessary device tree changes to enable analog audio output for the 3.5 mm TRS headphone jack on the Radxa ROCK 4C+ with its RK809 audio codec. Signed-off-by: Jonathan Liu <net147@gmail.com> Link: https://lore.kernel.org/r/20240828074755.1320692-1-net147@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-08-28KVM: SEV: Update KVM_AMD_SEV Kconfig entry and mention SEV-SNPVitaly Kuznetsov1-2/+4
SEV-SNP support is present since commit 1dfe571c12cf ("KVM: SEV: Add initial SEV-SNP support") but Kconfig entry wasn't updated and still mentions SEV and SEV-ES only. Add SEV-SNP there and, while on it, expand 'SEV' in the description as 'Encrypted VMs' is not what 'SEV' stands for. No functional change. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Link: https://lore.kernel.org/r/20240828122111.160273-1-vkuznets@redhat.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-08-28arm64: dts: rockchip: Add VPU121 support for RK3588Jianfeng Liu1-0/+21
Enable Hantro G1 video decoder in RK3588's devicetree. Tested with FFmpeg v4l2_request code taken from [1] with MPEG2, H.264 and VP8 samples. [1] https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/multimedia/ffmpeg/patches/v4l2-request/ffmpeg-001-v4l2-request.patch Signed-off-by: Jianfeng Liu <liujianfeng1994@gmail.com> Tested-by: Hugh Cole-Baker <sigmaris@gmail.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20240827181206.147617-3-sebastian.reichel@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-08-28arm64: dts: rockchip: Add VEPU121 to RK3588Emmanuel Gil Peyrot1-0/+80
RK3588 has 4 Hantro G1 encoder-only cores. They are all independent IP, but can be used as a cluster (i.e. sharing work between the cores). These cores are called VEPU121 in the TRM. The TRM describes one more VEPU121, but that is combined with a Hantro H1. That one will be handled using the VPU binding instead. Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20240827181206.147617-2-sebastian.reichel@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-08-28ARM: dts: rockchip: Add vpu nodes for RK3128Alex Bee1-0/+24
Add nodes for the vpu and it's attached iommu which are both part of the RK3128_PD_VIDEO powerdomain. Signed-off-by: Alex Bee <knaerzche@gmail.com> Link: https://lore.kernel.org/r/20240523185633.71355-4-knaerzche@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-08-28x86/resctrl: Fix arch_mbm_* array overrun on SNCPeter Newman2-6/+8
When using resctrl on systems with Sub-NUMA Clustering enabled, monitoring groups may be allocated RMID values which would overrun the arch_mbm_{local,total} arrays. This is due to inconsistencies in whether the SNC-adjusted num_rmid value or the unadjusted value in resctrl_arch_system_num_rmid_idx() is used. The num_rmid value for the L3 resource is currently: resctrl_arch_system_num_rmid_idx() / snc_nodes_per_l3_cache As a simple fix, make resctrl_arch_system_num_rmid_idx() return the SNC-adjusted, L3 num_rmid value on x86. Fixes: e13db55b5a0d ("x86/resctrl: Introduce snc_nodes_per_l3_cache") Signed-off-by: Peter Newman <peternewman@google.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lore.kernel.org/r/20240822190212.1848788-1-peternewman@google.com
2024-08-28ARM: dts: imx7-mba7: improve compatible for LM75 temp sensorMarkus Niebel1-1/+1
Use national,lm75a to specify exact variant used. This should cause no functional changes. Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-08-28ARM: dts: imx7-mba7: add iio-hwmon supportMarkus Niebel1-0/+6
Enable IIO hwmon support for ADC1 and ADC2. All channels are available on X23 (ADC2) and X24 (ADC1) of MBa7x. Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-08-28arm64: dts: mba8mx: Add Ethernet PHY IRQ supportAlexander Stein1-0/+2
The interrupt pin of the PHY is connected to the GPIO expander, configure it accordingly. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-08-28arm64: dts: layerscape: remove unused num-viewportAnimesh Agarwal1-1/+0
Remove unused property num-viewport to fix dtbs warnings. arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dtb: pcie@3400000: Unevaluated properties are not allowed ('num-viewport' was unexpected) from schema $id: http://devicetree.org/schemas/pci/fsl,layerscape-pcie.yaml# arch/arm64/boot/dts/freescale/fsl-ls1012a-oxalis.dtb: pcie@3400000: Unevaluated properties are not allowed ('num-viewport' was unexpected) from schema $id: http://devicetree.org/schemas/pci/fsl,layerscape-pcie.yaml# Cc: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Animesh Agarwal <animeshagarwal28@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-08-27s390/ftrace: Avoid calling unwinder in ftrace_return_address()Vasily Gorbik2-20/+16
ftrace_return_address() is called extremely often from performance-critical code paths when debugging features like CONFIG_TRACE_IRQFLAGS are enabled. For example, with debug_defconfig, ftrace selftests on my LPAR currently execute ftrace_return_address() as follows: ftrace_return_address(0) - 0 times (common code uses __builtin_return_address(0) instead) ftrace_return_address(1) - 2,986,805,401 times (with this patch applied) ftrace_return_address(2) - 140 times ftrace_return_address(>2) - 0 times The use of __builtin_return_address(n) was replaced by return_address() with an unwinder call by commit cae74ba8c295 ("s390/ftrace: Use unwinder instead of __builtin_return_address()") because __builtin_return_address(n) simply walks the stack backchain and doesn't check for reaching the stack top. For shallow stacks with fewer than "n" frames, this results in reads at low addresses and random memory accesses. While calling the fully functional unwinder "works", it is very slow for this purpose. Moreover, potentially following stack switches and walking past IRQ context is simply wrong thing to do for ftrace_return_address(). Reimplement return_address() to essentially be __builtin_return_address(n) with checks for reaching the stack top. Since the ftrace_return_address(n) argument is always a constant, keep the implementation in the header, allowing both GCC and Clang to unroll the loop and optimize it to the bare minimum. Fixes: cae74ba8c295 ("s390/ftrace: Use unwinder instead of __builtin_return_address()") Cc: stable@vger.kernel.org Reported-by: Sumanth Korikkar <sumanthk@linux.ibm.com> Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Acked-by: Sumanth Korikkar <sumanthk@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2024-08-27s390/build: Avoid relocation information in final vmlinuxJens Remus2-5/+41
Since commit 778666df60f0 ("s390: compile relocatable kernel without -fPIE") the kernel vmlinux ELF file is linked with --emit-relocs to preserve all relocations, so that all absolute relocations can be extracted using the 'relocs' tool to adjust them during boot. Port and adapt Petr Pavlu's x86 commit 9d9173e9ceb6 ("x86/build: Avoid relocation information in final vmlinux") to s390 to strip all relocations from the final vmlinux ELF file to optimize its size. Following is his original commit message with minor adaptions for s390: The Linux build process on s390 roughly consists of compiling all input files, statically linking them into a vmlinux ELF file, and then taking and turning this file into an actual bzImage bootable file. vmlinux has in this process two main purposes: 1) It is an intermediate build target on the way to produce the final bootable image. 2) It is a file that is expected to be used by debuggers and standard ELF tooling to work with the built kernel. For the second purpose, a vmlinux file is typically collected by various package build recipes, such as distribution spec files, including the kernel's own tar-pkg target. When building the kernel vmlinux contains also relocation information produced by using the --emit-relocs linker option. This is utilized by subsequent build steps to create relocs.S and produce a relocatable image. However, the information is not needed by debuggers and other standard ELF tooling. The issue is then that the collected vmlinux file and hence distribution packages end up unnecessarily large because of this extra data. The following is a size comparison of vmlinux v6.10 with and without the relocation information: | Configuration | With relocs | Stripped relocs | | defconfig | 696 MB | 320 MB | | -CONFIG_DEBUG_INFO | 48 MB | 32 MB | Optimize a resulting vmlinux by adding a postlink step that splits the relocation information into relocs.S and then strips it from the vmlinux binary. Reviewed-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Jens Remus <jremus@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2024-08-27s390/ftrace: Use kernel ftrace trampoline for modulesVasily Gorbik1-24/+0
Now that both the kernel modules area and the kernel image itself are located within 4 GB, there is no longer a need to maintain a separate ftrace_plt trampoline. Use the existing trampoline in the kernel. Reviewed-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2024-08-27s390/ftrace: Remove unused ftrace_plt_template*Vasily Gorbik1-2/+0
Unused since commit b860b9346e2d ("s390/ftrace: remove dead code"). Reviewed-by: Ilya Leoshkevich <iii@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2024-08-27KVM: arm64: Unify UNDEF injection helpersMarc Zyngier1-81/+51
We currently have two helpers (undef_access() and trap_undef()) that do exactly the same thing: inject an UNDEF and return 'false' (as an indication that PC should not be incremented). We definitely could do with one less. Given that undef_access() is used 80ish times, while trap_undef() is only used 30 times, the latter loses the battle and is immediately sacrificed. We also have a large number of instances where undef_access() is open-coded. Let's also convert those. Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20240827152517.3909653-11-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2024-08-27KVM: arm64: Make most GICv3 accesses UNDEF if they trapMarc Zyngier3-18/+66
We don't expect to trap any GICv3 register for host handling, apart from ICC_SRE_EL1 and the SGI registers. If they trap, that's because the guest is playing with us despite being told it doesn't have a GICv3. If it does, UNDEF is what it will get. Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20240827152517.3909653-10-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2024-08-27KVM: arm64: Honor guest requested traps in GICv3 emulationMarc Zyngier1-0/+72
On platforms that require emulation of the CPU interface, we still need to honor the traps requested by the guest (ICH_HCR_EL2 as well as the FGTs for ICC_IGRPEN{0,1}_EL1. Check for these bits early and lail out if any trap applies. Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20240827152517.3909653-9-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2024-08-27KVM: arm64: Add trap routing information for ICH_HCR_EL2Marc Zyngier1-5/+66
The usual song and dance. Anything that is a trap, any register it traps. Note that we don't handle the registers added by FEAT_NMI for now. Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20240827152517.3909653-8-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2024-08-27KVM: arm64: Add ICH_HCR_EL2 to the vcpu stateMarc Zyngier2-0/+4
As we are about to describe the trap routing for ICH_HCR_EL2, add the register to the vcpu state in its VNCR form, as well as reset Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20240827152517.3909653-7-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2024-08-27KVM: arm64: Zero ID_AA64PFR0_EL1.GIC when no GICv3 is presented to the guestMarc Zyngier2-4/+8
In order to be consistent, we shouldn't advertise a GICv3 when none is actually usable by the guest. Wipe the feature when these conditions apply, and allow the field to be written from userspace. This now allows us to rewrite the kvm_has_gicv3 helper() in terms of kvm_has_feat(), given that it is always evaluated at runtime. Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20240827152517.3909653-6-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2024-08-27KVM: arm64: Add helper for last ditch idreg adjustmentsMarc Zyngier4-17/+37
We already have to perform a set of last-chance adjustments for NV purposes. We will soon have to do the same for the GIC, so introduce a helper for that exact purpose. Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20240827152517.3909653-5-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2024-08-27KVM: arm64: Force GICv3 trap activation when no irqchip is configured on VHEMarc Zyngier1-4/+10
On a VHE system, no GICv3 traps get configured when no irqchip is present. This is not quite matching the "no GICv3" semantics that we want to present. Force such traps to be configured in this case. Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20240827152517.3909653-4-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2024-08-27KVM: arm64: Force SRE traps when SRE access is not enabledMarc Zyngier2-7/+20
We so far only write the ICH_HCR_EL2 config in two situations: - when we need to emulate the GICv3 CPU interface due to HW bugs - when we do direct injection, as the virtual CPU interface needs to be enabled This is all good. But it also means that we don't do anything special when we emulate a GICv2, or that there is no GIC at all. What happens in this case when the guest uses the GICv3 system registers? The *guest* gets a trap for a sysreg access (EC=0x18) while we'd really like it to get an UNDEF. Fixing this is a bit involved: - we need to set all the required trap bits (TC, TALL0, TALL1, TDIR) - for these traps to take effect, we need to (counter-intuitively) set ICC_SRE_EL1.SRE to 1 so that the above traps take priority. Note that doesn't fully work when GICv2 emulation is enabled, as we cannot set ICC_SRE_EL1.SRE to 1 (it breaks Group0 delivery as IRQ). Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20240827152517.3909653-3-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2024-08-27KVM: arm64: Move GICv3 trap configuration to kvm_calculate_traps()Marc Zyngier3-0/+12
Follow the pattern introduced with vcpu_set_hcr(), and introduce vcpu_set_ich_hcr(), which configures the GICv3 traps at the same point. This will allow future changes to introduce trap configuration on a per-VM basis. Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20240827152517.3909653-2-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2024-08-27Merge branch kvm-arm64/tlbi-fixes-6.12 into kvmarm-master/nextMarc Zyngier2-4/+4
* kvm-arm64/tlbi-fixes-6.12: : . : A couple of TLB invalidation fixes, only affecting pKVM : out of tree, courtesy of Will Deacon. : . KVM: arm64: Ensure TLBI uses correct VMID after changing context KVM: arm64: Invalidate EL1&0 TLB entries for all VMIDs in nvhe hyp init Signed-off-by: Marc Zyngier <maz@kernel.org>
2024-08-27arm64: tegra: Correct location of power-sensors for IGX OrinJon Hunter2-33/+33
The power-sensors are located on the carrier board