summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2025-05-09ARM: dts: ti: omap: use correct ohci/ehci node namesWolfram Sang
They should be named "usb@". Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20250330193833.21970-11-wsa+renesas@sang-engineering.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-05-09ARM: dts: st: use correct ohci/ehci node namesWolfram Sang
They should be named "usb@". Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20250330193833.21970-10-wsa+renesas@sang-engineering.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-05-09ARM: dts: nxp: lpc: use correct ohci/ehci node namesWolfram Sang
They should be named "usb@". Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20250330193833.21970-9-wsa+renesas@sang-engineering.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-05-09ARM: dts: marvell: use correct ohci/ehci node namesWolfram Sang
They should be named "usb@". Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20250330193833.21970-8-wsa+renesas@sang-engineering.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-05-09arm64: dts: amazon: Fix simple-bus node name schema warningsRob Herring (Arm)
Fix a couple of node name warnings from the schema checks: arch/arm64/boot/dts/amazon/alpine-v2-evp.dt.yaml: io-fabric: $nodename:0: 'io-fabric' does not match '^(bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$' arch/arm64/boot/dts/amazon/alpine-v3-evp.dt.yaml: io-fabric: $nodename:0: 'io-fabric' does not match '^(bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$' Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20250409210255.1541298-1-robh@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-05-09x86/its: Align RETs in BHB clear sequence to avoid thunkingPawan Gupta
The software mitigation for BHI is to execute BHB clear sequence at syscall entry, and possibly after a cBPF program. ITS mitigation thunks RETs in the lower half of the cacheline. This causes the RETs in the BHB clear sequence to be thunked as well, adding unnecessary branches to the BHB clear sequence. Since the sequence is in hot path, align the RET instructions in the sequence to avoid thunking. This is how disassembly clear_bhb_loop() looks like after this change: 0x44 <+4>: mov $0x5,%ecx 0x49 <+9>: call 0xffffffff81001d9b <clear_bhb_loop+91> 0x4e <+14>: jmp 0xffffffff81001de5 <clear_bhb_loop+165> 0x53 <+19>: int3 ... 0x9b <+91>: call 0xffffffff81001dce <clear_bhb_loop+142> 0xa0 <+96>: ret 0xa1 <+97>: int3 ... 0xce <+142>: mov $0x5,%eax 0xd3 <+147>: jmp 0xffffffff81001dd6 <clear_bhb_loop+150> 0xd5 <+149>: nop 0xd6 <+150>: sub $0x1,%eax 0xd9 <+153>: jne 0xffffffff81001dd3 <clear_bhb_loop+147> 0xdb <+155>: sub $0x1,%ecx 0xde <+158>: jne 0xffffffff81001d9b <clear_bhb_loop+91> 0xe0 <+160>: ret 0xe1 <+161>: int3 0xe2 <+162>: int3 0xe3 <+163>: int3 0xe4 <+164>: int3 0xe5 <+165>: lfence 0xe8 <+168>: pop %rbp 0xe9 <+169>: ret Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
2025-05-09x86/its: Add support for RSB stuffing mitigationPawan Gupta
When retpoline mitigation is enabled for spectre-v2, enabling call-depth-tracking and RSB stuffing also mitigates ITS. Add cmdline option indirect_target_selection=stuff to allow enabling RSB stuffing mitigation. When retpoline mitigation is not enabled, =stuff option is ignored, and default mitigation for ITS is deployed. Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Josh Poimboeuf <jpoimboe@kernel.org> Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
2025-05-09x86/its: Add "vmexit" option to skip mitigation on some CPUsPawan Gupta
Ice Lake generation CPUs are not affected by guest/host isolation part of ITS. If a user is only concerned about KVM guests, they can now choose a new cmdline option "vmexit" that will not deploy the ITS mitigation when CPU is not affected by guest/host isolation. This saves the performance overhead of ITS mitigation on Ice Lake gen CPUs. When "vmexit" option selected, if the CPU is affected by ITS guest/host isolation, the default ITS mitigation is deployed. Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Josh Poimboeuf <jpoimboe@kernel.org> Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
2025-05-09x86/its: Enable Indirect Target Selection mitigationPawan Gupta
Indirect Target Selection (ITS) is a bug in some pre-ADL Intel CPUs with eIBRS. It affects prediction of indirect branch and RETs in the lower half of cacheline. Due to ITS such branches may get wrongly predicted to a target of (direct or indirect) branch that is located in the upper half of the cacheline. Scope of impact =============== Guest/host isolation -------------------- When eIBRS is used for guest/host isolation, the indirect branches in the VMM may still be predicted with targets corresponding to branches in the guest. Intra-mode ---------- cBPF or other native gadgets can be used for intra-mode training and disclosure using ITS. User/kernel isolation --------------------- When eIBRS is enabled user/kernel isolation is not impacted. Indirect Branch Prediction Barrier (IBPB) ----------------------------------------- After an IBPB, indirect branches may be predicted with targets corresponding to direct branches which were executed prior to IBPB. This is mitigated by a microcode update. Add cmdline parameter indirect_target_selection=off|on|force to control the mitigation to relocate the affected branches to an ITS-safe thunk i.e. located in the upper half of cacheline. Also add the sysfs reporting. When retpoline mitigation is deployed, ITS safe-thunks are not needed, because retpoline sequence is already ITS-safe. Similarly, when call depth tracking (CDT) mitigation is deployed (retbleed=stuff), ITS safe return thunk is not used, as CDT prevents RSB-underflow. To not overcomplicate things, ITS mitigation is not supported with spectre-v2 lfence;jmp mitigation. Moreover, it is less practical to deploy lfence;jmp mitigation on ITS affected parts anyways. Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Josh Poimboeuf <jpoimboe@kernel.org> Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
2025-05-09x86/its: Add support for ITS-safe return thunkPawan Gupta
RETs in the lower half of cacheline may be affected by ITS bug, specifically when the RSB-underflows. Use ITS-safe return thunk for such RETs. RETs that are not patched: - RET in retpoline sequence does not need to be patched, because the sequence itself fills an RSB before RET. - RET in Call Depth Tracking (CDT) thunks __x86_indirect_{call|jump}_thunk and call_depth_return_thunk are not patched because CDT by design prevents RSB-underflow. - RETs in .init section are not reachable after init. - RETs that are explicitly marked safe with ANNOTATE_UNRET_SAFE. Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Josh Poimboeuf <jpoimboe@kernel.org> Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
2025-05-09x86/its: Add support for ITS-safe indirect thunkPawan Gupta
Due to ITS, indirect branches in the lower half of a cacheline may be vulnerable to branch target injection attack. Introduce ITS-safe thunks to patch indirect branches in the lower half of cacheline with the thunk. Also thunk any eBPF generated indirect branches in emit_indirect_jump(). Below category of indirect branches are not mitigated: - Indirect branches in the .init section are not mitigated because they are discarded after boot. - Indirect branches that are explicitly marked retpoline-safe. Note that retpoline also mitigates the indirect branches against ITS. This is because the retpoline sequence fills an RSB entry before RET, and it does not suffer from RSB-underflow part of the ITS. Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Josh Poimboeuf <jpoimboe@kernel.org> Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
2025-05-09x86/its: Enumerate Indirect Target Selection (ITS) bugPawan Gupta
ITS bug in some pre-Alderlake Intel CPUs may allow indirect branches in the first half of a cache line get predicted to a target of a branch located in the second half of the cache line. Set X86_BUG_ITS on affected CPUs. Mitigation to follow in later commits. Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Josh Poimboeuf <jpoimboe@kernel.org> Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
2025-05-09arm64: dts: rockchip: add Rock 5B+Sebastian Reichel
Add ROCK 5B+, which is an improved version of the ROCK 5B with the following changes: * Memory LPDDR4X -> LPDDR5 * HDMI input connector size * eMMC socket -> onboard * M.2 E-Key is replaced by onboard RTL8852BE WLAN/BT * M.2 M-Key 1x4 lanes is replaced by 2x2 lanes * Added M.2 B-Key for USB connected WWAN modules (untested) * Add second camera port (not yet supported in upstream Linux) * Add dedicated USB-C port for device power (no impact in DT; the existing port has not been changed and the new port is handled by CH224D standalone chip) Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20250508-rock5bp-for-upstream-v2-4-677033cc1ac2@kernel.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-05-09arm64: dts: rockchip: move rock 5b to include fileSebastian Reichel
Radxa released some more boards, which are based on the original Rock 5B. Move its board description into an include file to avoid unnecessary duplication. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20250508-rock5bp-for-upstream-v2-1-677033cc1ac2@kernel.org Link: https://lore.kernel.org/r/20250508-rock5bp-for-upstream-v2-2-677033cc1ac2@kernel.org [The original submission was split into two elements, renaming the file and then moving some nodes around. This was done to make review easier due to the diff being smaller. This commit is a squash of both of them to facilitate bisectability and was also intended by the original author] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-05-09arm64: dts: rockchip: Add rk3399-evb-ind boardChaoyi Chen
General feature for rk3399 industry evaluation board: - Rockchip RK3399 - 4GB LPDDR4 - emmc5.1 - SDIO3.0 compatible TF card - 1x HDMI2.0a TX - 1x HDMI1.4b RX with TC358749XBG HDMI to MIPI CSI2 bridge chip - 1x type-c DisplayPort - 3x USB3.0 Host - 1x USB2.0 Host - 1x Ethernet / USB3.0 to Ethernet Tested with HDMI/GPU/USB2.0/USB3.0/TF card/emmc. Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com> Link: https://lore.kernel.org/r/20250506034347.57-3-kernel@airkyi.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-05-09arm64: defconfig: Enable Rockchip SAI and ES8328Nicolas Frattaroli
The RK3576 uses Rockchip SAI for audio output. Meanwhile, the Sige5 board, which uses the RK3576 and is supported by mainline, uses an ES8388 codec over I2C with the ES8328 driver implementing support for this codec. Enable both in the defconfig. Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://lore.kernel.org/r/20250506-rk3576-sai-v4-5-a8b5f5733ceb@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-05-09arm64: dts: rockchip: Enable HDMI audio on Sige5Nicolas Frattaroli
With the hdmi_sound node added to the base RK3576 SoC tree, we can now enable it on the Sige5 SBC. Do this, and also enable the corresponding SAI6 audio controller node. Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://lore.kernel.org/r/20250506-rk3576-sai-v4-4-a8b5f5733ceb@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-05-09arm64: dts: rockchip: Add analog audio on RK3576 Sige5Nicolas Frattaroli
The ArmSoM Sige5 board features an Everest ES8388 codec to provide analog stereo audio output, as well as analog audio input. The codec hangs off the i2c2 bus and responds to address 0x10. It is connected to the SAI1 audio controller of the RK3576, with one SDO (output) lane and one SDI (input) lane. The codec has two sets of outputs. One set, LOUT1/ROUT1, is connected through a set of 22uF non-polarised coupling capacitors to a 3-position connector that appears to be a clone of the JST BM03B-SURS-TF header, and is capable of mating with a JST 03SUR-32S (or JST 03SUR-36L if you prefer lemon-lime) or compatible clone connector. The right headphone output is the one closest to the Type-C DC input connector, the left headphone output is the one in the middle, and the third position, the one closest to the USB3 Type-A host connector, is puzzingly labelled as "HP_GND" in the schematic but is in fact connected to the codecs RIN1 input through a 1uF non-plarised coupling capacitor. LOUT2 and ROUT2 are routed to 1mm test pads T36 and T37 respectively. These are located on the bottom of the board, and do not go through any coupling capacitor. For use as line out, the ES8388 datasheet recommends adding 1uF coupling capacitor if one wishes to use it as a line-level output. There is also a pair of inputs for a stereo microphone, going from two 1mm testpads T34 and T35, which are decoupled with a 100pF capacitor and pulled to 3.3v and ground respectively. These inputs then go through 1uF capacitors each and end up in the LINPUT2 and RINPUT2 pins of the ES8388 codec. The codec's power inputs are routed to receive 3.3V for both its analog and digital inputs, though from different supplies. Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://lore.kernel.org/r/20250506-rk3576-sai-v4-3-a8b5f5733ceb@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-05-09arm64: dts: rockchip: Add RK3576 HDMI audioNicolas Frattaroli
The RK3576 SoC now has upstream support for HDMI. Add an HDMI audio node, which uses SAI6 as its audio controller according to downstream. Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://lore.kernel.org/r/20250506-rk3576-sai-v4-2-a8b5f5733ceb@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-05-09arm64: dts: rockchip: Add RK3576 SAI nodesNicolas Frattaroli
The RK3576 SoC has 10 SAI controllers in total. Five of them are in the video output power domains, and are used for digital audio output along with the video signal of those, e.g. HDMI audio. The other five, SAI0 through SAI4, are exposed externally. SAI0 and SAI1 are capable of 8-channel audio, whereas SAI2, SAI3 and SAI4 are limited to two channels. These five are in the audio power domain. Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://lore.kernel.org/r/20250506-rk3576-sai-v4-1-a8b5f5733ceb@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-05-09arm64: dts: rockchip: Enable SD-card interface on Radxa E20CYao Zi
SD-card is available on Radxa E20C board. Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Jonas Karlman <jonas@kwiboo.se> Link: https://lore.kernel.org/r/20250508234829.27111-4-ziyao@disroot.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-05-09arm64: dts: rockchip: Add SDMMC/SDIO controllers for RK3528Yao Zi
RK3528 features two SDIO controllers and one SD/MMC controller, describe them in devicetree. Since their sample and drive clocks are located in the VO and VPU GRFs, corresponding syscons are added to make these clocks available. Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Jonas Karlman <jonas@kwiboo.se> Link: https://lore.kernel.org/r/20250508234829.27111-3-ziyao@disroot.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-05-09Merge tag 'arm64-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fix from Catalin Marinas: "Move the arm64_use_ng_mappings variable from the .bss to the .data section as it is accessed very early during boot with the MMU off and before the .bss has been initialised. This could lead to incorrect idmap page table" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: cpufeature: Move arm64_use_ng_mappings to the .data section to prevent wrong idmap generation
2025-05-09Merge tag 'riscv-for-linus-6.15-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Palmer Dabbelt: - The compressed half-word misaligned access instructions (c.lhu, c.lh, and c.sh) from the Zcb extension are now properly emulated - A series of fixes to properly emulate permissions while handling userspace misaligned accesses - A pair of fixes for PR_GET_TAGGED_ADDR_CTRL to avoid accessing the envcfg CSR on systems that don't support that CSR, and to report those failures up to userspace - The .rela.dyn section is no longer stripped from vmlinux, as it is necessary to relocate the kernel under some conditions (including kexec) * tag 'riscv-for-linus-6.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: Disallow PR_GET_TAGGED_ADDR_CTRL without Supm scripts: Do not strip .rela.dyn section riscv: Fix kernel crash due to PR_SET_TAGGED_ADDR_CTRL riscv: misaligned: use get_user() instead of __get_user() riscv: misaligned: enable IRQs while handling misaligned accesses riscv: misaligned: factorize trap handling riscv: misaligned: Add handling for ZCB instructions
2025-05-09bpf, riscv64: Skip redundant zext instruction after load-acquirePeilin Ye
Currently, the verifier inserts a zext instruction right after every 8-, 16- or 32-bit load-acquire, which is already zero-extending. Skip such redundant zext instructions. While we are here, update that already-obsolete comment about "skip the next instruction" in build_body(). Also change emit_atomic_rmw()'s parameters to keep it consistent with emit_atomic_ld_st(). Note that checking 'insn[1]' relies on 'insn' not being the last instruction, which should have been guaranteed by the verifier; we already use 'insn[1]' elsewhere in the file for similar purposes. Additionally, we don't check if 'insn[1]' is actually a zext for our load-acquire's dst_reg, or some other registers - in other words, here we are relying on the verifier to always insert a redundant zext right after a 8/16/32-bit load-acquire, for its dst_reg. Acked-by: Björn Töpel <bjorn@kernel.org> Reviewed-by: Pu Lehui <pulehui@huawei.com> Tested-by: Björn Töpel <bjorn@rivosinc.com> # QEMU/RVA23 Signed-off-by: Peilin Ye <yepeilin@google.com> Link: https://lore.kernel.org/r/10e90e0eab042f924d35ad0d1c1f7ca29f673152.1746588351.git.yepeilin@google.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-05-09bpf, riscv64: Support load-acquire and store-release instructionsAndrea Parri
Support BPF load-acquire (BPF_LOAD_ACQ) and store-release (BPF_STORE_REL) instructions in the riscv64 JIT compiler. For example, consider the following 64-bit load-acquire (assuming little-endian): db 10 00 00 00 01 00 00 r1 = load_acquire((u64 *)(r1 + 0x0)) 95 00 00 00 00 00 00 00 exit opcode (0xdb): BPF_ATOMIC | BPF_DW | BPF_STX imm (0x00000100): BPF_LOAD_ACQ The JIT compiler will emit an LD instruction followed by a FENCE R,RW instruction for the above, e.g.: ld x7,0(x6) fence r,rw Similarly, consider the following 16-bit store-release: cb 21 00 00 10 01 00 00 store_release((u16 *)(r1 + 0x0), w2) 95 00 00 00 00 00 00 00 exit opcode (0xcb): BPF_ATOMIC | BPF_H | BPF_STX imm (0x00000110): BPF_STORE_REL A FENCE RW,W instruction followed by an SH instruction will be emitted, e.g.: fence rw,w sh x2,0(x4) 8-bit and 16-bit load-acquires are zero-extending (cf., LBU, LHU). The verifier always rejects misaligned load-acquires/store-releases (even if BPF_F_ANY_ALIGNMENT is set), so the emitted load and store instructions are guaranteed to be single-copy atomic. Introduce primitives to emit the relevant (and the most common/used in the kernel) fences, i.e. fences with R -> RW, RW -> W and RW -> RW. Rename emit_atomic() to emit_atomic_rmw() to make it clear that it only handles RMW atomics, and replace its is64 parameter to allow to perform the required checks on the opsize (BPF_SIZE(code)). Acked-by: Björn Töpel <bjorn@kernel.org> Tested-by: Björn Töpel <bjorn@rivosinc.com> # QEMU/RVA23 Signed-off-by: Andrea Parri <parri.andrea@gmail.com> Co-developed-by: Peilin Ye <yepeilin@google.com> Signed-off-by: Peilin Ye <yepeilin@google.com> Reviewed-by: Pu Lehui <pulehui@huawei.com> Link: https://lore.kernel.org/r/3059c560e537ad43ed19055d2ebbd970c698095a.1746588351.git.yepeilin@google.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-05-09bpf, riscv64: Introduce emit_load_*() and emit_store_*()Andrea Parri
We're planning to add support for the load-acquire and store-release BPF instructions. Define emit_load_<size>() and emit_store_<size>() to enable/facilitate the (re)use of their code. Acked-by: Björn Töpel <bjorn@kernel.org> Reviewed-by: Pu Lehui <pulehui@huawei.com> Tested-by: Björn Töpel <bjorn@rivosinc.com> # QEMU/RVA23 Tested-by: Peilin Ye <yepeilin@google.com> Signed-off-by: Andrea Parri <parri.andrea@gmail.com> [yepeilin@google.com: cosmetic change to commit title] Signed-off-by: Peilin Ye <yepeilin@google.com> Link: https://lore.kernel.org/r/fce89473a5748e1631d18a5917d953460d1ae0d0.1746588351.git.yepeilin@google.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-05-09Merge tag 'asahi-soc-fixes-6.15' of https://github.com/AsahiLinux/linux into ↵Arnd Bergmann
arm/fixes Apple SoC fixes for 6.15 This tag contains two small commits since rc1: - Add a .mailmap entry requested by Asahi Lina to better filter her emails - Mark the power domains for the touchbar support introduced with 6.15 as always on since the driver cannot initialize the touchbar from scratch after the domains are powered off (e.g. during suspend). * tag 'asahi-soc-fixes-6.15' of https://github.com/AsahiLinux/linux: arm64: dts: apple: touchbar: Mark ps_dispdfr_be as always-on mailmap: Update email for Asahi Lina Link: https://lore.kernel.org/r/20250423145047.3098-1-sven@svenpeter.dev Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-05-09Merge tag 'riscv-sophgo-dt-fixes-for-v6.15-rc1' of ↵Arnd Bergmann
https://github.com/sophgo/linux into arm/fixes RISC-V Sophgo Devicetree fixes for v6.15-rc1 Just one minor fix to correct DMA data-width configuration for CV18xx. Signed-off-by: Chen Wang <unicorn_wang@outlook.com> * tag 'riscv-sophgo-dt-fixes-for-v6.15-rc1' of https://github.com/sophgo/linux: riscv: dts: sophgo: fix DMA data-width configuration for CV18xx Link: https://lore.kernel.org/r/MA0P287MB2262454C19B8899BC1694D04FE832@MA0P287MB2262.INDP287.PROD.OUTLOOK.COM Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-05-09Merge tag 'amlogic-fixes-for-v6.15' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux into arm/fixes Amlogic Fixes for v6.15: - fix reference to unknown/untested PWM clock on ARM/ARM64 boards - fix missing clkc_audio node on dreambox ARM64 DT * tag 'amlogic-fixes-for-v6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux: arm64: dts: amlogic: dreambox: fix missing clkc_audio node arm64: dts: amlogic: g12: fix reference to unknown/untested PWM clock arm64: dts: amlogic: gx: fix reference to unknown/untested PWM clock ARM: dts: amlogic: meson8b: fix reference to unknown/untested PWM clock ARM: dts: amlogic: meson8: fix reference to unknown/untested PWM clock Link: https://lore.kernel.org/r/e9c520a1-b986-49e1-b9b1-67511c187716@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-05-09Merge tag 'v6.15-rockchip-dtsfixes1' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/fixes Removal of operating-points above what the rk3588j soc is rated for, and a number of smaller fixes: Turing RK1 fan can spin down again, fixed pins, pinmuxing and clocks and some devicetree-correctnes improvements. * tag 'v6.15-rockchip-dtsfixes1' of https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: arm64: dts: rockchip: fix Sige5 RTC interrupt pin arm64: dts: rockchip: Assign RT5616 MCLK rate on rk3588-friendlyelec-cm3588 arm64: dts: rockchip: Align wifi node name with bindings in CB2 arm64: dts: rockchip: Fix mmc-pwrseq clock name on rock-pi-4 arm64: dts: rockchip: Use "regulator-fixed" for btreg on px30-engicam for vcc3v3-btreg arm64: dts: rockchip: Add pinmuxing for eMMC on QNAP TS433 arm64: dts: rockchip: Remove overdrive-mode OPPs from RK3588J SoC dtsi arm64: dts: rockchip: Allow Turing RK1 cooling fan to spin down Link: https://lore.kernel.org/r/2923598.88bMQJbFj6@diego Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-05-09ARM: dts: amlogic: meson8-fernsehfee3: Describe regulatorsJ. Neuschäfer
The fernsehfee3 board uses a Ricoh RN5T618 PMIC to generate various voltages. Board schematics are not available, but the regulator voltages found in /sys/kernel/debug/regulator/regulator_summary match those in meson8m2-mxiii-plus.dts: DCDC1 0 0 0 unknown 1100mV 0mA 0mV 0mV DCDC2 0 0 0 unknown 1150mV 0mA 0mV 0mV DCDC3 0 0 0 unknown 1500mV 0mA 0mV 0mV LDO1 0 0 0 unknown 2900mV 0mA 0mV 0mV LDO2 0 0 0 unknown 1800mV 0mA 0mV 0mV LDO3 0 0 0 unknown 1800mV 0mA 0mV 0mV LDO4 0 0 0 unknown 2850mV 0mA 0mV 0mV LDO5 0 0 0 unknown 1800mV 0mA 0mV 0mV LDORTC1 0 0 0 unknown 2700mV 0mA 0mV 0mV LDORTC2 0 0 0 unknown 900mV 0mA 0mV 0mV This patch takes the following approach: - Copy RN5T618 regulator nodes from meson8m2-mxiii-plus.dts - Remove some of the regulator names, which do not seem to apply - Verify regulator supply relations by starting without any relations (and without regulator-always-on) and seeing what breaks when the kernel turns off "unused" regulators. This results in the following observations: - When LDO1 is turned off, the board resets - When DCDC1, DCDC2, DCDC3, LDO2, or LDO5 are turned off, the board (as observed through the serial port) stops running, so these must stay on at all times. - LDO4 (VCC2V8) appears to be unused on this board. - LDO3 (VCC1V8_USB) must stay on in order for USB to work, both the external USB ports and the internal USB wifi module. The cpu-supply and mali-supply relations are also copied from meson8m2-mxiii-plus.dts Signed-off-by: J. Neuschäfer <j.ne@posteo.net> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/20250428-fernsehfee-v2-4-293b98a43a91@posteo.net Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2025-05-09ARM: dts: amlogic: Add TCU Fernsehfee 3.0J. Neuschäfer
Fernsehfee[1] ("TV fairy") 3.0 is a set-top box with HDMI input and output ports. It originally ran Android 4.4 and a Linux 3.10 kernel. The following features are tested and known to work: - Ethernet - Power LED (switching between green and red) - Power button - eMMC - SD Card - USB - Wifi The following features are untested or not working: - HDMI input and output - Infrared remote control input and output [1]: https://fernsehfee.de/ (German), https://telefairy.com/ (English) Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: J. Neuschäfer <j.ne@posteo.net> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/20250428-fernsehfee-v2-3-293b98a43a91@posteo.net Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2025-05-09x86/mm: Eliminate window where TLB flushes may be inadvertently skippedDave Hansen
tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm. But should_flush_tlb() has a bug and suppresses the flush. Fix it by widening the window where should_flush_tlb() sends an IPI. Long Version: === History === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so it was made lazier. But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask(). So code was added to cull mm_cpumask() periodically[2]. But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them. So here we are again. === Problem === The too-aggressive code in should_flush_tlb() strikes in this window: // Turn on IPIs for this CPU/mm combination, but only // if should_flush_tlb() agrees: cpumask_set_cpu(cpu, mm_cpumask(next)); next_tlb_gen = atomic64_read(&next->context.tlb_gen); choose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); load_new_mm_cr3(need_flush); // ^ After 'need_flush' is set to false, IPIs *MUST* // be sent to this CPU and not be ignored. this_cpu_write(cpu_tlbstate.loaded_mm, next); // ^ Not until this point does should_flush_tlb() // become true! should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed. Whoops. === Solution === Thankfully, the fuzzy "just about to write CR3" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI. This will cause more TLB flush IPIs. But the window is relatively small and I do not expect this to cause any kind of measurable performance impact. Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user. Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: Rik van Riel <riel@surriel.com> Link: https://lore.kernel.org/oe-lkp/202411282207.6bd28eae-lkp@intel.com/ [1] Fixes: 6db2526c1d69 ("x86/mm/tlb: Only trim the mm_cpumask once a second") [2] Reported-by: Stephen Dolan <sdolan@janestreet.com> Cc: stable@vger.kernel.org Acked-by: Ingo Molnar <mingo@kernel.org> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2025-05-09ARM: dts: mxs: use padconfig macrosDario Binacchi
Convert mx2{3,8} dts files to use the padconfig macros defined in mxs-pinfunc.h. Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-05-09arm64: dts: freescale: Add PHYTEC phyBOARD-Nash-i.MX93 supportPrimoz Fiser
Add initial support for PHYTEC phyBOARD-Nash-i.MX93 board [1] based on the PHYTEC phyCORE-i.MX93 SoM (System-on-Module) [2]. Supported board features: * ADC * CAN * Ethernet * EEPROM * RTC * RS-232/RS-485 * SD-card * TPM 2.0 * USB For more details see the product pages for the development kit and the SoM: [1] https://www.phytec.eu/en/produkte/development-kits/phyboard-nash/ [2] https://www.phytec.eu/en/produkte/system-on-modules/phycore-imx-91-93/ Signed-off-by: Primoz Fiser <primoz.fiser@norik.com> Reviewed-by: Wadim Egorov <w.egorov@phytec.de> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-05-09arm64: dts: imx8mp-var-som: Fix LDO5 shutdown causing SD card timeoutHimanshu Bhavani
Fix SD card timeout issue caused by LDO5 regulator getting disabled after boot. The kernel log shows LDO5 being disabled, which leads to a timeout on USDHC2: [ 33.760561] LDO5: disabling [ 81.119861] mmc1: Timeout waiting for hardware interrupt. To prevent this, set regulator-boot-on and regulator-always-on for LDO5. Also add the vqmmc regulator to properly support 1.8V/3.3V signaling for USDHC2 using a GPIO-controlled regulator. Fixes: 6c2a1f4f71258 ("arm64: dts: imx8mp-var-som-symphony: Add Variscite Symphony board and VAR-SOM-MX8MP SoM") Signed-off-by: Himanshu Bhavani <himanshu.bhavani@siliconsignals.io> Acked-by: Tarang Raval <tarang.raval@siliconsignals.io> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-05-09arm64: defconfig: Add Toradex Embedded Controller configFrancesco Dolcini
Enable config for Toradex SMARC Embedded Controller, this is required for proper reset and power-off functionalities on Toradex SMARC iMX8M Plus. Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-05-09arm64: dts: freescale: imx8mp-toradex-smarc: use generic gpio node nameFrancesco Dolcini
Use generic node name for the SoM GPIO expander, following the Devicetree Specification generic node names recommendation. Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-05-09arm64: dts: freescale: imx8mp-toradex-smarc: add gpio expanderEmanuele Ghidoli
Add gpio expander node to the device tree and the related nodes. Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-05-09arm64: dts: freescale: imx8mp-toradex-smarc: add embedded controllerEmanuele Ghidoli
Add the embedded controller node to the device tree, this is required for reset and power-off functionalities. Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-05-09arm64: dts: freescale: imx8mp-toradex-smarc: add fan PWM configurationFrancesco Dolcini
Configure correctly the FAN pwm output (inverted). Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-05-09arm64: dts: imx93-tqma9352-mba91xxca: disable Open Drain for MDIOMarkus Niebel
Using the MDIO pins with Open Drain causes spec violations of the signals. Revert the changes. This is similar to commit 14e66e4b13221 ("Revert "arm64: dts: imx93-tqma9352-mba93xxca: enable Open Drain for MDIO"") Fixes: e5bc07026f94 ("arm64: add initial device tree for TQMa93xx/MBa91xxCA") Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-05-09arm64: dt: imx95: Add TQMa95xxSAAlexander Stein
Add initial support for TQMa95xxSA module compatible to SMARC-2. There is a common device tree for all variants with e.g. reduced CPU count. It supports LPUART7 for console, CAN, PCIe I2C, SPI, USB3.0, USB2.0, Audio, SDHC1/2 and QSPI as storage. [1] https://www.tq-group.com/en/products/tq-embedded/arm-architecture/tqma95xxsa/ Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-05-09arm64/cpuinfo: only show one cpu's info in c_show()Ye Bin
Currently, when ARM64 displays CPU information, every call to c_show() assembles all CPU information. However, as the number of CPUs increases, this can lead to insufficient buffer space due to excessive assembly in a single call, causing repeated expansion and multiple calls to c_show(). To prevent this invalid c_show() call, only one CPU's information is assembled each time c_show() is called. Signed-off-by: Ye Bin <yebin10@huawei.com> Link: https://lore.kernel.org/r/20250421062947.4072855-1-yebin@huaweicloud.com Signed-off-by: Will Deacon <will@kernel.org>
2025-05-09ARM: dts: imx7d: update opp-table voltagesEfe Can İçöz
Update accepted voltage levels according to IMX7DCEC Table 9 Operating ranges Signed-off-by: Efe Can İçöz <efecanicoz@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-05-09ARM: dts: nxp: Align wifi node name with bindingsKrzysztof Kozlowski
Since commit 3c3606793f7e ("dt-bindings: wireless: bcm4329-fmac: Use wireless-controller.yaml schema"), bindings expect 'wifi' as node name: imx7d-remarkable2.dtb: bcrmf@1: $nodename:0: 'bcrmf@1' does not match '^wifi(@.*)?$' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-05-09arm64: dts: imx: Align wifi node name with bindingsKrzysztof Kozlowski
Since commit 3c3606793f7e ("dt-bindings: wireless: bcm4329-fmac: Use wireless-controller.yaml schema"), bindings expect 'wifi' as node name: imx8mm-var-som-symphony.dtb: bcrmf@1: $nodename:0: 'bcrmf@1' does not match '^wifi(@.*)?$' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-05-09arm64: dts: freescale: add initial device tree for TQMa8XxSAlexander Stein
This adds support for TQMa8XQPS and TQMa8XDPS modules on MB-SMARC-2 board. As the only difference is the mounted SoC, both module and baseboard files are shared. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-05-09arm64: dts: imx8mp-tqma8mpql-mba8mp-ras314: Add Raspberry Pi Camera V2 overlayAlexander Stein
This overlay configures IMX219 MIPI-CSI-2 camera attached to ISP1. Also add additional overlay both using LVDS display and camera. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
generated by cgit (git 2.34.1) at 2025-07-18 23:54:51 +0000