summaryrefslogtreecommitdiff
path: root/arch/arm64
AgeCommit message (Collapse)AuthorFilesLines
7 daysarm64: Reserve an extra page for early kernel mappingZhaoyang Huang1-1/+6
[ Upstream commit 4d8e74ad4585672489da6145b3328d415f50db82 ] The final part of [data, end) segment may overflow into the next page of init_pg_end[1] which is the gap page before early_init_stack[2]: [1] crash_arm64_v9.0.1> vtop ffffffed00601000 VIRTUAL PHYSICAL ffffffed00601000 83401000 PAGE DIRECTORY: ffffffecffd62000 PGD: ffffffecffd62da0 => 10000000833fb003 PMD: ffffff80033fb018 => 10000000833fe003 PTE: ffffff80033fe008 => 68000083401f03 PAGE: 83401000 PTE PHYSICAL FLAGS 68000083401f03 83401000 (VALID|SHARED|AF|NG|PXN|UXN) PAGE PHYSICAL MAPPING INDEX CNT FLAGS fffffffec00d0040 83401000 0 0 1 4000 reserved [2] ffffffed002c8000 (r) __pi__data ffffffed0054e000 (d) __pi___bss_start ffffffed005f5000 (b) __pi_init_pg_dir ffffffed005fe000 (b) __pi_init_pg_end ffffffed005ff000 (B) early_init_stack ffffffed00608000 (b) __pi__end For 4K pages, the early kernel mapping may use 2MB block entries but the kernel segments are only 64KB aligned. Segment boundaries that fall within a 2MB block therefore require a PTE table so that different attributes can be applied on either side of the boundary. KERNEL_SEGMENT_COUNT still correctly counts the five permanent kernel VMAs registered by declare_kernel_vmas(). However, since commit 5973a62efa34 ("arm64: map [_text, _stext) virtual address range non-executable+read-only"), the early mapper also maps [_text, _stext) separately from [_stext, _etext). This adds one more early-only split and can require one more page-table page than the existing EARLY_SEGMENT_EXTRA_PAGES allowance reserves. Increase the 4K-page early mapping allowance by one page to cover that additional split. Fixes: 5973a62efa34 ("arm64: map [_text, _stext) virtual address range non-executable+read-only") Assisted-by: TRAE:GLM-5.1 Suggested-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com> [catalin.marinas@arm.com: rewrote part of the commit log] [catalin.marinas@arm.com: expanded the code comment] Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64/scs: Fix potential sign extension issue of advance_loc4Wentao Guan1-2/+2
[ Upstream commit 4023b7424ecd5d38cc75b650d6c1bf630ef8cb40 ] The expression (*opcode++ << 24) and exp * code_alignment_factor may overflow signed int and becomes negative. Fix this by casting each byte to u64 before shifting. Also fix the misaligned break statement while we are here. Example of the result can be seen here: Link: https://godbolt.org/z/zhY8d3595 It maybe not a real problem, but could be a issue in future. Fixes: d499e9627d70 ("arm64/scs: Fix handling of advance_loc4") Signed-off-by: Wentao Guan <guanwentao@uniontech.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: meson-gxl-p230: fix ethernet PHY interrupt numberJun Yan1-1/+2
[ Upstream commit 174a0ef3b33434f475c87e66f37980e39b73805a ] Correct the interrupt number assigned to the Realtek PHY in the p230 following the same logic as commit 3106507e1004 ("ARM64: dts: meson-gxm: fix q200 interrupt number"),as reported in [PATCH 0/2] Ethernet PHY interrupt improvements [1]. [1] https://lore.kernel.org/all/20171202214037.17017-1-martin.blumenstingl@googlemail.com/ Fixes: b94d22d94ad2 ("ARM64: dts: meson-gx: add external PHY interrupt on some platforms") Signed-off-by: Jun Yan <jerrysteve1101@gmail.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://patch.msgid.link/20260330145111.115318-1-jerrysteve1101@gmail.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: amlogic: meson-axg: Add missing cache information to cpu0Anand Moon1-0/+6
[ Upstream commit 918273be0885362a9a00615b46e03f15f8b55667 ] Add missing L1 data and instruction cache parameters to the CPU node 0 for the Cortex-A53 caches on the Meson AXG SoC. Fixes: 3b6ad2a43367 ("arm64: dts: amlogic: Add cache information to the Amlogic AXG SoCS") Signed-off-by: Anand Moon <linux.amoon@gmail.com> Link: https://patch.msgid.link/20260219103548.18392-1-linux.amoon@gmail.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: marvell: armada-37xx: use 'usb2-phy' in USB3 controller's phy-namesGabor Juhos2-2/+2
[ Upstream commit 0fef19844624f8bc07651b4d26088d8940affba3 ] Instead of the generic 'usb2-phy' name, the Armada 37xx device trees are using a custom 'usb2-utmi-otg-phy' name for the USB2 PHY in the USB3 controller node. Since commit 53a2d95df836 ("usb: core: add phy notify connect and disconnect"), this triggers a bug [1] in the USB core which causes double use of the USB3 PHY. Change the PHY name to 'usb2-phy' in the SoC and in the uDPU specific dtsi files in order to avoid triggering the bug and also to keep the names in line with the ones used by other platforms. Link: https://lore.kernel.org/r/20260330-usb-avoid-usb3-phy-double-use-v1-1-d2113aecb535@gmail.com # [1] Fixes: 53a2d95df836 ("usb: core: add phy notify connect and disconnect") Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: imx8mm-tqma8mqml: Correct PAD settings for PMIC_nINTPeng Fan1-1/+1
[ Upstream commit 42a9f5a16328ed78a88e0498556965b6c6ec515c ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. Fixes: dfcd1b6f7620e ("arm64: dts: freescale: add initial device tree for TQMa8MQML with i.MX8MM") Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: imx8mn-tqma8mqnl: Correct PAD settings for PMIC_nINTPeng Fan1-1/+1
[ Upstream commit 0fb37990774113afd943eaa91323679388584b6d ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. Fixes: 3e56e354db6d3 ("arm64: dts: freescale: add initial device tree for TQMa8MQNL with i.MX8MN") Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: imx8mm-emtop-som: Correct PAD settings for PMIC_nINTPeng Fan1-2/+2
[ Upstream commit 721dec3ee9ff5231d13a412ff87df63b966d137b ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. While at here, also correct interrupt type as IRQ_TYPE_LEVEL_LOW. Fixes: cbd3ef64eb9d1 ("arm64: dts: Add support for Emtop SoM & Baseboard") Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: imx8mp-data-modul-edm-sbc: Correct PAD settings for PMIC_nINTPeng Fan1-1/+1
[ Upstream commit 8ff145577e93f312ff398cb950ee3bd44835f5be ] PMIC_nINT is low level triggered, but the current PAD settings is PE=0,PUE=0,FSEL_1_FAST_SLEW_RATE=1,SION=1. So PAD needs to be configured as PULL UP with PULL Enable, no need SION. Correct it. Fixes: 562d222f23f0f ("arm64: dts: imx8mp: Add support for Data Modul i.MX8M Plus eDM SBC") Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: imx8mp-dhcom-som: Correct PAD settings for PMIC_nINTPeng Fan1-1/+1
[ Upstream commit f9ed5afc988da3e22543725e35be6addbb0497bc ] PMIC_nINT is low level triggered, but the current PAD settings is PE=0,PUE=0,FSEL_1_FAST_SLEW_RATE=1,SION=1. So PAD needs to be configured as PULL UP with PULL Enable, no need SION. Correct it. Fixes: 8d6712695bc8e ("arm64: dts: imx8mp: Add support for DH electronics i.MX8M Plus DHCOM and PDK2") Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: imx8mp-ultra-mach-sbc: Correct PAD settings for PMIC_nINTPeng Fan1-2/+2
[ Upstream commit daaf41ee72fb5fad936e7051a015cccae9b33937 ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. Fixes: d1c1400bd3b8b ("arm64: dts: imx8mp: Add initial support for Ultratronik imx8mp-ultra-mach-sbc board") Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: imx8mp-sr-som: Correct PAD settings for PMIC_nINTPeng Fan1-2/+2
[ Upstream commit 695a476275cfb9c798a696aeaa43967701d5c78a ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. Fixes: a009c0c66ecb4 ("arm64: dts: add description for solidrun imx8mp som and cubox-m") Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Josua Mayer <josua@solid-run.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: imx8mp-nitrogen-som: Correct PAD settings for PMIC_nINTPeng Fan1-1/+1
[ Upstream commit 16611eda2c7584a1a7d6f80511d825e5108f026c ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. Fixes: ab4d874c9f44e ("arm64: dts: imx8mp: Add device tree for Nitrogen8M Plus ENC Carrier Board") Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: imx8mp-aristainetos3a-som-v1: Correct PAD settings for PMIC_nINTPeng Fan1-1/+1
[ Upstream commit e6d2d8e49ca34bb39126a69128794d08ffd7c83e ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. Fixes: eead8f3536d5c ("arm64: dts: imx8mp: add aristainetos3 board support") Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: imx8mp-edm-g: Correct PAD settings for PMIC_nINTPeng Fan1-1/+1
[ Upstream commit c46c5a54443440ce0f71de9f4df9dd860f5c2afd ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. Fixes: 95e882c021c8b ("arm64: dts: imx8mp: Add TechNexion EDM-G-IMX8M-PLUS SOM on WB-EDM-G carrier board") Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: imx8mp-icore-mx8mp: Correct PAD settings for PMIC_nINTPeng Fan1-1/+1
[ Upstream commit ea8c90f5c7ceeb6657a8fe564aa7b190dce298a6 ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. Fixes: eefe06b295087 ("arm64: dts: imx8mp: Add Engicam i.Core MX8M Plus SoM") Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: imx8mp-navqp: Correct PAD settings for PMIC_nINTPeng Fan1-1/+1
[ Upstream commit 741d6ac1a2a2e0f3e2cae5eef3516cdd75119e83 ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there will be interrupt storm for i.MX8MP NAVQP. Per schematic, there is no on board PULL-UP resistors for GPIO1_IO03, so need to set PAD PUE and PU together to make pull up work properly. Fixes: 682729a9d506d ("arm64: dts: freescale: Add device tree for Emcraft Systems NavQ+ Kit") Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: imx8mp-debix-som-a: Correct PAD settings for PMIC_nINTPeng Fan2-2/+2
[ Upstream commit 2ea7872048a179b0ea8dadc67771961df3f0fc4a ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there is interrupt storm for i.MX8MP DEBIX SOM A. Need to set PAD PUE and PU together to make pull up work properly. Fixes: 21baf0b47f81b ("arm64: dts: freescale: Add DEBIX SOM A and SOM A I/O Board support") Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Closes: https://lore.kernel.org/all/20260323105858.GA2185714@killaraus.ideasonboard.com/ Reported-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Closes: https://lore.kernel.org/imx/20260324194353.GB2352505@killaraus.ideasonboard.com/T/#m9a07fdc75496369a7d76d52c5e34ed140dcabfe3 Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: imx8mp-debix-model-a: Correct PAD settings for PMIC_nINTPeng Fan1-1/+1
[ Upstream commit 3b778178997aee24537b521a8cb60970bc1ce01c ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there is interrupt storm for i.MX8MP DEBIX Model A. Per schematic, there is no on board PULL-UP resistors for GPIO1_IO03, so need to set PAD PUE and PU together to make pull up work properly. Fixes: c86d350aae68e ("arm64: dts: Add device tree for the Debix Model A Board") Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Closes: https://lore.kernel.org/all/20260323105858.GA2185714@killaraus.ideasonboard.com/ Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysbpf, arm64: Remove redundant bpf_flush_icache() after pack allocator finalizePuranjay Mohan1-12/+0
[ Upstream commit 42f18ae53011826cfd3c84d041817e7f07bc645b ] bpf_flush_icache() calls flush_icache_range() to clean the data cache and invalidate the instruction cache for the JITed code region. However, since commit 1dad391daef1 ("bpf, arm64: use bpf_prog_pack for memory management"), this flush is redundant. bpf_jit_binary_pack_finalize() copies the JITed instructions to the ROX region via bpf_arch_text_copy() -> aarch64_insn_copy() -> __text_poke(), and __text_poke() already calls flush_icache_range() on the written range. The subsequent bpf_flush_icache() repeats the same cache maintenance on an overlapping range, including an unnecessary second synchronous IPI to all CPUs via kick_all_cpus_sync(). Remove the redundant bpf_flush_icache() call and its now-unused definition. Fixes: 1dad391daef1 ("bpf, arm64: use bpf_prog_pack for memory management") Acked-by: Song Liu <song@kernel.org> Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Acked-by: Breno Leitao <leitao@debian.org> Link: https://lore.kernel.org/r/20260413191111.3426023-2-puranjay@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysbpf, arm64: Fix off-by-one in check_imm signed range checkDaniel Borkmann1-2/+2
[ Upstream commit 1dd8be4ec722ce54e4cace59f3a4ba658111b3ec ] check_imm(bits, imm) is used in the arm64 BPF JIT to verify that a branch displacement (in arm64 instruction units) fits into the signed N-bit immediate field of a B, B.cond or CBZ/CBNZ encoding before it is handed to the encoder. The macro currently tests for (imm > 0 && imm >> bits) || (imm < 0 && ~imm >> bits) which admits values in [-2^N, 2^N) — effectively a signed (N+1)-bit range. A signed N-bit field only holds [-2^(N-1), 2^(N-1)), so the check admits one extra bit of range on each side. In particular, for check_imm19(), values in [2^18, 2^19) slip past the check but do not fit into the 19-bit signed imm19 field of B.cond. aarch64_insn_encode_immediate() then masks the raw value into the 19-bit field, setting bit 18 (the sign bit) and flipping a forward branch into a backward one. Same class of issue exists for check_imm26() and the B/BL encoding. Shift by (bits - 1) instead of bits so the actual signed N-bit range is enforced. Fixes: e54bcde3d69d ("arm64: eBPF JIT compiler") Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Puranjay Mohan <puranjay@kernel.org> Link: https://lore.kernel.org/r/20260415121403.639619-2-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysbpf, arm64: Reject out-of-range B.cond targetsDaniel Borkmann1-0/+2
[ Upstream commit 48d83d94930eb4db4c93d2de44838b9455cff626 ] aarch64_insn_gen_cond_branch_imm() calls label_imm_common() to compute a 19-bit signed byte offset for a conditional branch, but unlike its siblings aarch64_insn_gen_branch_imm() and aarch64_insn_gen_comp_branch_imm(), it does not check whether label_imm_common() returned its out-of-range sentinel (range) before feeding the value to aarch64_insn_encode_immediate(). aarch64_insn_encode_immediate() unconditionally masks the value with the 19-bit field mask, so an offset that was rejected by label_imm_common() gets silently truncated. With the sentinel value SZ_1M, the resulting field ends up with bit 18 (the sign bit of the 19-bit signed displacement) set, and the CPU decodes it as a ~1 MiB *backward* branch, producing an incorrectly targeted B.cond instruction. For code-gen locations like the emit_bpf_tail_call() this function is the only barrier between an overflowing displacement and a silently miscompiled branch. Fix it by returning AARCH64_BREAK_FAULT when the offset is out of range, so callers see a loud failure instead of a silently misencoded branch. validate_code() scans the generated image for any AARCH64_BREAK_FAULT and then lets the JIT fail. Fixes: 345e0d35ecdd ("arm64: introduce aarch64_insn_gen_cond_branch_imm()") Fixes: c94ae4f7c5ec ("arm64: insn: remove BUG_ON from codegen") Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Puranjay Mohan <puranjay@kernel.org> Link: https://lore.kernel.org/r/20260415121403.639619-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64/xor: fix conflicting attributes for xor_block_templateChristoph Hellwig1-1/+1
[ Upstream commit 675a0dd596e712404557286d0a883b54ee28e4f4 ] Commit 2c54b423cf85 ("arm64/xor: use EOR3 instructions when available") changes the definition to __ro_after_init instead of const, but failed to update the external declaration in xor.h. This was not found because xor-neon.c doesn't include <asm/xor.h>, and can't easily do that due to current architecture of the XOR code. Link: https://lkml.kernel.org/r/20260327061704.3707577-4-hch@lst.de Fixes: 2c54b423cf85 ("arm64/xor: use EOR3 instructions when available") Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Eric Biggers <ebiggers@kernel.org> Tested-by: Eric Biggers <ebiggers@kernel.org> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Alexandre Ghiti <alex@ghiti.fr> Cc: Andreas Larsson <andreas@gaisler.com> Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: "Borislav Petkov (AMD)" <bp@alien8.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Chris Mason <clm@fb.com> Cc: Christian Borntraeger <borntraeger@linux.ibm.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: David S. Miller <davem@davemloft.net> Cc: David Sterba <dsterba@suse.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Huacai Chen <chenhuacai@kernel.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jason A. Donenfeld <jason@zx2c4.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Li Nan <linan122@huawei.com> Cc: Madhavan Srinivasan <maddy@linux.ibm.com> Cc: Magnus Lindholm <linmag7@gmail.com> Cc: Matt Turner <mattst88@gmail.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Richard Weinberger <richard@nod.at> Cc: Russell King <linux@armlinux.org.uk> Cc: Song Liu <song@kernel.org> Cc: Sven Schnelle <svens@linux.ibm.com> Cc: Ted Ts'o <tytso@mit.edu> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: WANG Xuerui <kernel@xen0n.name> Cc: Will Deacon <will@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: qcom: sm8250: Add missing CPU7 3.09GHz OPPAlexander Koskovich1-0/+5
[ Upstream commit b683730e27ba4f91986c4c92f5cb7297f1e01a6d ] This resolves the following error seen on the ASUS ROG Phone 3: cpu cpu7: Voltage update failed freq=3091200 cpu cpu7: failed to update OPP for freq=3091200 Fixes: 8e0e8016cb79 ("arm64: dts: qcom: sm8250: Add CPU opp tables") Signed-off-by: Alexander Koskovich <akoskovich@pm.me> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260307-sm8250-cpu7-opp-v1-1-435f5f6628a1@pm.me Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: qcom: milos: Add missing CX power domain to GCCAbel Vesa1-0/+2
[ Upstream commit e46b48b853122626806d989d5db4ce97eaaac2ca ] Unless CX is declared as the power-domain of GCC, votes (power and performance) on the GDSCs it provides will not propagate to the CX, which might result in under-voltage conditions. Add the missing power-domains property to associate GCC with RPMHPD_CX. Fixes: d9d59d105f98 ("arm64: dts: qcom: Add initial Milos dtsi") Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260327-dt-fix-milos-eliza-gcc-power-domains-v1-2-f14a22c73fe9@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: tegra: Fix RTC aliasesJon Hunter2-0/+2
[ Upstream commit 69ec77b3f1074f3000d28f67f7629303e7999b84 ] The following warning is observed on the Tegra234 Jetson platforms ... rtc-nvidia-vrs10 4-003c: /aliases ID 0 not available This happens because the 'rtc@c2a0000' device is registered before the vrs10 RTC and so is assigned the 'rtc0' alias. We want the vrs10 RTC to be the default RTC because this RTC maintains time across power cycles. Fix this by adding a 'rtc1' alias for the 'rtc@c2a0000' device. Fixes: b1806f2b4e78 ("arm64: tegra: Add device-tree node for NVVRS RTC") Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: imx8qxp-mek: switch Type-C connector power-role to dualXu Yang1-1/+9
[ Upstream commit 825b8c7e1d2918d89eb378b761530d1e51dba82e ] When attach to PC Type-A port, the USB device controller does not function at all. Because it is configured as source-only and a Type-A port doesn't support PD capability, a data role swap is impossible. Actually, PTN5110THQ is configured for Source role only at POR, but after POR it can operate as a DRP (Dual-Role Power). By switching the power-role to dual, the port can operate as a sink and enter device mode when attach to Type-A port. Since the board design uses EN_SRC to control the 5V VBUS path and EN_SNK to control the 12V VBUS output, to avoid outputting a higher VBUS when in sink role, we set the operation current limit to 0mA so that SW will not control EN_SNK at all. Fixes: 2faf4ebcee2e5 ("arm64: dts: freescale: imx8qxp-mek: enable cadence usb3") Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: imx8qm-mek: switch Type-C connector power-role to dualXu Yang1-1/+9
[ Upstream commit e3d3d19d1c0050789a4813ce836a641a3387d916 ] When attach to PC Type-A port, the USB device controller does not function at all. Because it is configured as source-only and a Type-A port doesn't support PD capability, a data role swap is impossible. Actually, PTN5110THQ is configured for Source role only at POR, but after POR it can operate as a DRP (Dual-Role Power). By switching the power-role to dual, the port can operate as a sink and enter device mode when attach to Type-A port. Since the board design uses EN_SRC to control the 5V VBUS path and EN_SNK to control the 12V VBUS output, to avoid outputting a higher VBUS when in sink role, we set the operation current limit to 0mA so that SW will not control EN_SNK at all. Fixes: b237975b2cd58 ("arm64: dts: imx8qm-mek: add usb 3.0 and related type C nodes") Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: lx2160a: complete pinmux for rcwsr12 configuration wordJosua Mayer1-0/+75
[ Upstream commit 284ad7064aaa1badde022785cd925af29c696b21 ] Commit 8a1365c7bbc1 ("arm64: dts: lx2160a: add pinmux and i2c gpio to support bus recovery") introduced pinmux nodes for lx2160 i2c interfaces, allowing runtime change between i2c and gpio functions implementing bus recovery. However, the dynamic configuration area (overwrite MUX) used by the pinctrl-single driver initially reads as zero and does not reflect the actual hardware state set by the Reset Configuration Word (RCW) at power-on. Because multiple groups of pins are configured from a single 32-bit register, the first write from the pinctrl driver unintentionally clears all other bits to zero. Add description for all bits of RCWSR12 register, allowing boards to explicitly define and restore their intended hardware state. This includes i2c, gpio, flextimer, spi, can and sdhc functions. Other configuration words, i.e. RCWSR13 & RCWSR14 may be added in the future for boards setting non-zero values there. Fixes: 8a1365c7bbc1 ("arm64: dts: lx2160a: add pinmux and i2c gpio to support bus recovery") Signed-off-by: Josua Mayer <josua@solid-run.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: lx2160a: change zeros to hexadecimal in pinmux nodesJosua Mayer1-5/+5
[ Upstream commit 03241620d2b9915c9e3463dbc56e9eb95ad43c08 ] Replace some stray zeros from decimal to hexadecimal format within pinmux nodes. No functional change intended. Fixes: 8a1365c7bbc1 ("arm64: dts: lx2160a: add pinmux and i2c gpio to support bus recovery") Signed-off-by: Josua Mayer <josua@solid-run.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: lx2160a: add sda gpio references for i2c bus recoveryJosua Mayer1-0/+8
[ Upstream commit 89ea0dbd701f89805499d26bd90657468c789545 ] LX2160A pinmux is done in groups by various length bitfields within configuration registers. In particular i2c sda/scl pins are always configured together. Therefore bus recovery may control both sda and scl. When pinmux nodes and bus recovery was enabled originally for LX2160, only the scl-gpios were added to the i2c controller nodes. Add references to sda-gpios for each i2c controller. Fixes: 8a1365c7bbc1 ("arm64: dts: lx2160a: add pinmux and i2c gpio to support bus recovery") Signed-off-by: Josua Mayer <josua@solid-run.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: lx2160a: rename pinmux nodes for readabilityJosua Mayer1-32/+32
[ Upstream commit 456eb494746afd56d3a9dc30271300136e55b96e ] LX2160A pinmux is done in groups by various length bitfields within configuration registers. Each group of pins is named in the reference manual after a primary function using soc-specific naming, e.g. IIC1 (for i2c0). Hardware block numbering starts from zero in device-tree but one in the reference manual. Rename the already defined pinmux nodes originally added for changing i2c pins between i2c and gpio functions reflecting the reference manual name (IIC) in the node name, and the device-tree name (i2c, gpio) in the label. Specifically, drop the "_scl" suffix from the I2C labels because the nodes actually configure both SDA and SCL pins together. Instead add "_pins" suffix to avoid conflicts with I2C controller labels. For GPIO functions, include the specific controller and pin numbers in the label to clarify they are generic GPIOs and help spot mistakes. No functional change intended. Fixes: 8a1365c7bbc1 ("arm64: dts: lx2160a: add pinmux and i2c gpio to support bus recovery") Signed-off-by: Josua Mayer <josua@solid-run.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: lx2160a: remove duplicate pinmux nodesJosua Mayer1-10/+2
[ Upstream commit 325ca511ca3dda936207ce737e0afe837d45a674 ] LX2160A pinmux is done in groups by various length bitfields within configuration registers. The pinmux nodes i2c7-scl-pins and i2c7-scl-gpio-pins are duplicates of i2c6-scl-gpio and i2c6-scl-gpio-pins, writing to the same register and bits. These two i2c buses i2c6/i2c7 (IIC7/IIC8) are configured together in register RCWSR13 bits 3-0. Drop the duplicate node name and change references to the i2c6 node. Fixes: 8a1365c7bbc1 ("arm64: dts: lx2160a: add pinmux and i2c gpio to support bus recovery") Signed-off-by: Josua Mayer <josua@solid-run.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: lx2160a: change i2c0 (iic1) pinmux mask to one bitJosua Mayer1-2/+2
[ Upstream commit 7a3cc49ad1fc8d063abb7f5de8f1b981b99d2978 ] LX2160A pinmux is done in groups by various length bitfields within configuration registers. The first i2c bus (called IIC1 in reference manual) is configured through field IIC1_PMUX in register RCWSR14 bit 10 which is described in the reference manual as a single bit, unlike the other i2c buses. Change the bitmask for the pinmux nodes from 0x7 to 0x1 to ensure only single bit is modified. Further change the zero in the same line to hexadecimal format for consistency. Align with documentation by avoiding writes to reserved bits. No functional change, as writing the extra two reserved bits is not known to cause issues. Fixes: 8a1365c7bbc1 ("arm64: dts: lx2160a: add pinmux and i2c gpio to support bus recovery") Signed-off-by: Josua Mayer <josua@solid-run.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: imx8mp-evk: Specify ADV7535 register addressesLiu Ying1-1/+2
[ Upstream commit bfb91be0eba426913f2950ed8b3d963f0de53fcc ] MIPI DSI to HDMI bridge ADV7535 CEC default register address is 0x3c on an I2C bus. And, OV5640 camera uses the same address on the same I2C bus. To resolve this conflict, use 0x3b as ADV7535 CEC register address by specifying all ADV7535 register addresses. Fixes: 6f6c18cba16f ("arm64: dts: imx8mp-evk: add camera ov5640 and related nodes") Signed-off-by: Liu Ying <victor.liu@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: imx8dxl-evk: Use audio-graph-card2 for wm8960-2 and wm8960-3Shengjiu Wang1-24/+90
[ Upstream commit e8341b0245736619f8d6a2cc311c9e8ad8e82390 ] The sound card wm8960-2 and wm8960-3 only support capture mode for the reason of connection on the EVK board. But fsl-asoc-card don't support capture_only setting, the sound card creation will fail. fsl-sai 59060000.sai: Missing dma channel for stream: 0 fsl-sai 59060000.sai: ASoC error (-22): at snd_soc_pcm_component_new() on 59060000.sai fsl-sai 59070000.sai: Missing dma channel for stream: 0 fsl-sai 59070000.sai: ASoC error (-22): at snd_soc_pcm_component_new() on 59070000.sai so switch to use audio-graph-card2 which supports 'capture_only' property for wm8960-2 and wm8960-3 cards. Fixes: b41c45eb990a ("arm64: dts: imx8dxl-evk: add audio nodes") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: imx8mp-kontron: Fix boot order for PMIC and RTCAnnette Kobou1-0/+6
[ Upstream commit 130d90114c5255a7a729158da8fd8298a02017f1 ] The PMIC provides a level-shifter for the I2C lines to the RTC. As the level shifter needs to be enabled before the RTC can be accessed, make sure that the PMIC driver is probed first. As the PMIC also provides the supply voltage for the RTC through the 3.3V regulator, simply express this in the DT to create the required dependency. Avoid sporadic boot hangs that occurred when the RTC was accessed before the level-shifter was enabled. Fixes: 946ab10e3f40f ("arm64: dts: Add support for Kontron OSM-S i.MX8MP SoM and BL carrier board") Signed-off-by: Annette Kobou <annette.kobou@kontron.de> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: imx91: Remove TMU's superfluous sensor IDAlexander Stein1-1/+1
[ Upstream commit 53a0485304f11f5371fddf9fb06b95268154bf82 ] Currently a sensor ID is added to the reference, but thermal-sensor@44482000 has #thermal-sensor-cells = <0>, so parsing fails. This also has the effect that other hwmon sensors (jc42) fail to probe. Fix this by removing the superfluous sensor ID. Fixes: f0ed0e844452 ("arm64: dts: imx91: Add thermal-sensor and thermal-zone support") Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: freescale: imx8mp-tqma8mpql-mba8mp-ras314: fix UART1 RTS/CTS muxingNora Schiffer1-2/+2
[ Upstream commit b8d785a9f360abcd6a6f8f10a2adf222f8494d66 ] UART1 operates in DCE mode, but the RTS/CTS pins were incorrectly configured using the DTE pinmux setting. Correct the pinmux to match DCE mode. Switching the RTS and CTS signals is fine for this board, as UART1 is routed to a pin header. Existing functionality is unaffected, as RTS/CTS could never have worked with the incorrect pinmux. Fixes: ddabb3ce3f90 ("arm64: dts: freescale: add TQMa8MPQL on MBa8MP-RAS314") Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com> Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: ti: k3-am62-verdin: Fix SPI_1 GPIO CS pinctrl labelFrancesco Dolcini1-1/+1
[ Upstream commit 944dffaec1ef0f21c203728de77b5618ed70df6e ] Fix SPI_1_CS GPIO pinmux label, this is spi1_cs, not qspi1_io4. There are no user of this label yet, therefore this change does not create any compatibility issue. Fixes: fcb335934c51 ("arm64: dts: ti: verdin-am62: Improve spi1 chip-select pinctrl") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://patch.msgid.link/20260324093705.26730-3-francesco@dolcini.it Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: ti: k3-am62-lp-sk: Enable internal pulls for MMC0 data pinsJudith Mendez1-7/+7
[ Upstream commit ee2a9d9c9e6c9643fb7e45febcaedfbc038e483a ] AM62 LP SK board does not have external pullups on MMC0 DAT1-DAT7 pins [0]. Enable internal pullups on DAT1-DAT7 considering: - without a host-side pullup, these lines rely solely on the eMMC device's internal pullup (R_int, 10-150K per JEDEC), which may exceed the recommended 50K max for 1.8V VCCQ - JEDEC JESD84-B51 Table 200 requires host-side pullups (R_DAT, 10K-100K) on all data lines to prevent bus floating [0] https://www.ti.com/lit/zip/SPRR471 Fixes: a0b8da04153e ("arm64: dts: ti: k3-am62*: Move eMMC pinmux to top level board file") Signed-off-by: Judith Mendez <jm@ti.com> Reviewed-by: Moteen Shah <m-shah@ti.com> Link: https://patch.msgid.link/20260223233731.2690472-4-jm@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: ti: k3-am62l3-evm: Disable MMC1 internal pulls on data pinsJudith Mendez1-3/+3
[ Upstream commit 02532ba56362907b6aca3e8289c4a9247ef83325 ] AM62L EVM has external 47K pullups on MMC1 DAT1-DAT3 pins [0]. Disable internal pullups on DAT1-DAT3 so that each line has a single pullup source: - with both pullups enabled, the effective parallel resistance on DAT1-3 (~24.2K) creates a ~2x mismatch vs DAT0 (47K external only). Removing internal pullups results in DAT1-3 matching DAT0 at 47K - 47K external alone is within the recommended range for 1.8V signaling (10K min, 50K recommended max) - both internal and external pullups enabled equals unnecessary power consumption [0] https://www.ti.com/lit/zip/SPRCAL6 Fixes: 00fb4c73b67d ("arm64: dts: ti: k3-am62l: add initial reference board file") Signed-off-by: Judith Mendez <jm@ti.com> Reviewed-by: Moteen Shah <m-shah@ti.com> Link: https://patch.msgid.link/20260223233731.2690472-3-jm@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: ti: k3-am62p5-sk: Disable MMC1 internal pulls on data pinsJudith Mendez1-3/+3
[ Upstream commit 6d4441be969bea89bb9702781f5dfb3a8f2a02a4 ] AM62P SK has external 10K pullups on MMC1 DAT1-DAT3 pins [0]. Disable internal pullups on DAT1-DAT3 so that each line has a single pullup source: - with both pullups enabled, the effective parallel resistance on DAT1-3 (~8.33K) drops below the 10K minimum pullup requirement for data lines (per SD Physical Layer Specification) - removing internal pullups makes DAT1-3 match DAT0 10K external pullup so its consistent and within spec - both internal and external pullups enabled equals unnecessary power consumption [0] https://www.ti.com/lit/zip/SPRR487 Fixes: c00504ea42c0 ("arm64: dts: ti: k3-am62p5-sk: Updates for SK EVM") Signed-off-by: Judith Mendez <jm@ti.com> Reviewed-by: Moteen Shah <m-shah@ti.com> Link: https://patch.msgid.link/20260223233731.2690472-2-jm@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: qcom: msm8917-xiaomi-riva: Fix board-id for all bootloaderBarnabás Czémán1-1/+1
[ Upstream commit a49cd243503c528ea99e31a7853cf438ccc9032d ] Redmi 5A comes with multiple bootloader versions where the expected board-id is different. Change the board-id to unified form what works on both bootloader version. Fixes: 26633b582056 ("arm64: dts: qcom: Add Xiaomi Redmi 5A") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260315-riva-common-v3-1-897f130786ed@mainlining.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: qcom: sdm845-xiaomi-beryllium: Mark l1a regulator as powered ↵David Heidelberg1-0/+1
during boot [ Upstream commit 3b0dd81eea6b7a239fce456ce4545af76f1a9715 ] The regulator must be on, since it provides the display subsystem and therefore the bootloader had turned it on before Linux booted. Fixes: 77809cf74a8c ("arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)") Signed-off-by: David Heidelberg <david@ixit.cz> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260320-beryllium-booton-v2-1-931d1be21eae@ixit.cz Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: qcom: sm7225-fairphone-fp4: Fix conflicting bias pinctrlLuca Weiss1-0/+4
[ Upstream commit be7c1badb0b934cfe88427b1d4ec3eb9f52ba587 ] The pinctrl nodes from sm6350.dtsi already contain a bias-* property, so that needs to be deleted, otherwise the dtb will contain two conflicting bias-* properties. Reported-by: Conor Dooley <conor@kernel.org> Closes: https://lore.kernel.org/r/20260310-maritime-silly-05e7b7e03aa6@spud/ Fixes: c4ef464b24c5 ("arm64: dts: qcom: sm7225-fairphone-fp4: Add Bluetooth") Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20260319-fp4-uart1-fix-v1-1-f6b3fedef583@fairphone.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: qcom: sm8650: Enable UHS-I SDR50 and SDR104 SD card modesVladimir Zapolskiy1-3/+0
[ Upstream commit 93f823e7d48232e62fb8fb74481696609c90244a ] The restriction on UHS-I speed modes was added to all SM8650 platforms by copying it from SM8450 and SM8550 dtsi files, and it was an actually reproducible problem due to the overclocking of SD cards. Since the latter issue has been fixed in the SM8650 GCC driver, UHS-I speed modes are working fine on SM8650 boards, below is the test performed on SM8650-HDK: SDR50 speed mode: mmc0: new UHS-I speed SDR50 SDHC card at address 0001 mmcblk0: mmc0:0001 00000 14.6 GiB mmcblk0: p1 % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 24.8086 s, 43.3 MB/s SDR104 speed mode: mmc0: new UHS-I speed SDR104 SDHC card at address 59b4 mmcblk0: mmc0:59b4 USDU1 28.3 GiB mmcblk0: p1 % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 12.9448 s, 82.9 MB/s Unset the UHS-I speed mode restrictions from the SM8550 platform dtsi file, there is no indication that the SDHC controller is broken. Fixes: 10e024671295 ("arm64: dts: qcom: sm8650: add interconnect dependent device nodes") Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Link: https://lore.kernel.org/r/20260314023715.357512-7-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: qcom: sm8550: Enable UHS-I SDR50 and SDR104 SD card modesVladimir Zapolskiy1-3/+0
[ Upstream commit 66b0f024fba0728ddce6916dce173bb1bdd4eab0 ] The restriction on UHS-I speed modes was added to all SM8550 platforms by copying it from SM8450 dtsi file, and due to the overclocking of SD cards it was an actually reproducible problem. Since the latter issue has been fixed, UHS-I speed modes are working fine on SM8550 boards, below is the test performed on SM8550-HDK: SDR50 speed mode: mmc0: new UHS-I speed SDR50 SDHC card at address 0001 mmcblk0: mmc0:0001 00000 14.6 GiB mmcblk0: p1 % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 23.5468 s, 45.6 MB/s SDR104 speed mode: mmc0: new UHS-I speed SDR104 SDHC card at address 59b4 mmcblk0: mmc0:59b4 USDU1 28.3 GiB mmcblk0: p1 % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 11.9819 s, 89.6 MB/s Unset the UHS-I speed mode restrictions from the SM8550 platform dtsi file, there is no indication that the SDHC controller is broken. Fixes: ffc50b2d3828 ("arm64: dts: qcom: Add base SM8550 dtsi") Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Link: https://lore.kernel.org/r/20260314023715.357512-6-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: qcom: sm8450: Enable UHS-I SDR50 and SDR104 SD card modesVladimir Zapolskiy1-3/+0
[ Upstream commit db0c5ef1abda6effdc5c85d6688fb6af2b351ae5 ] The reported problem of some non-working UHS-I speed modes on SM8450 originates in commit 0a631a36f724 ("arm64: dts: qcom: Add device tree for Sony Xperia 1 IV"), and then it was spread to all SM8450 powered platforms by commit 9d561dc4e5cc ("arm64: dts: qcom: sm8450: disable SDHCI SDR104/SDR50 on all boards"). The tests show that the rootcause of the problem was related to an overclocking of SD cards, and it's fixed later on by commit a27ac3806b0a ("clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs"). Since then both SDR50 and SDR104 speed modes are working fine on SM8450, tested on SM8450-HDK: SDR50 speed mode: mmc0: new UHS-I speed SDR50 SDHC card at address 0001 mmcblk0: mmc0:0001 00000 14.6 GiB mmcblk0: p1 % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 24.6254 s, 43.6 MB/s SDR104 speed mode: mmc0: new UHS-I speed SDR104 SDHC card at address 59b4 mmcblk0: mmc0:59b4 USDU1 28.3 GiB mmcblk0: p1 % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 12.3266 s, 87.1 MB/s Remove the restrictions on SD card speed modes from the SM8450 platform dtsi file and enable UHS-I speed modes. Fixes: 9d561dc4e5cc ("arm64: dts: qcom: sm8450: disable SDHCI SDR104/SDR50 on all boards") Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Link: https://lore.kernel.org/r/20260314023715.357512-5-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
7 daysarm64: dts: qcom: hamoa: Fix xo clock supply of platform SD host controllerVladimir Zapolskiy1-2/+2
[ Upstream commit d094f79960e1da20c1380083c95945371baa3668 ] The expected frequency of SD host controller core supply clock is 19.2MHz, while RPMH_CXO_CLK clock frequency on SM8650 platform is 38.4MHz. Apparently the overclocked supply clock could be good enough on some boards and even with the most of SD cards, however some low-end UHS-I SD cards in SDR104 mode of the host controller produce I/O errors in runtime, fortunately this problem is gone, if the "xo" clock frequency matches the expected 19.2MHz clock rate. Fixes: ffb21c1e19b1 ("arm64: dts: qcom: x1e80100: Describe the SDHC controllers") Reported-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20260314023715.357512-4-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-05-30 13:40:46 +0300