summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2025-07-14smpboot: introduce SDTL_INIT() helper to tidy sched topology setupLi Chen
Define a small SDTL_INIT(maskfn, flagsfn, name) macro and use it to build the sched_domain_topology_level array. Purely a cleanup; behaviour is unchanged. Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Li Chen <chenl311@chinatelecom.cn> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com> Tested-by: K Prateek Nayak <kprateek.nayak@amd.com> Link: https://lore.kernel.org/r/20250710105715.66594-2-me@linux.beauty
2025-07-13mm/balloon_compaction: convert balloon_page_delete() to balloon_page_finalize()David Hildenbrand
Let's move the removal of the page from the balloon list into the single caller, to remove the dependency on the PG_isolated flag and clarify locking requirements. Note that for now, balloon_page_delete() was used on two paths: (1) Removing a page from the balloon for deflation through balloon_page_list_dequeue() (2) Removing an isolated page from the balloon for migration in the per-driver migration handlers. Isolated pages were already removed from the balloon list during isolation. So instead of relying on the flag, we can just distinguish both cases directly and handle it accordingly in the caller. We'll shuffle the operations a bit such that they logically make more sense (e.g., remove from the list before clearing flags). In balloon migration functions we can now move the balloon_page_finalize() out of the balloon lock and perform the finalization just before dropping the balloon reference. Document that the page lock is currently required when modifying the movability aspects of a page; hopefully we can soon decouple this from the page lock. Link: https://lkml.kernel.org/r/20250704102524.326966-3-david@redhat.com Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: Alistair Popple <apopple@nvidia.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Brendan Jackman <jackmanb@google.com> Cc: Byungchul Park <byungchul@sk.com> Cc: Chengming Zhou <chengming.zhou@linux.dev> Cc: Christian Brauner <brauner@kernel.org> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: Eugenio Pé rez <eperezma@redhat.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Gregory Price <gourry@gourry.net> Cc: Harry Yoo <harry.yoo@oracle.com> Cc: "Huang, Ying" <ying.huang@linux.alibaba.com> Cc: Jan Kara <jack@suse.cz> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Jason Wang <jasowang@redhat.com> Cc: Jerrin Shaji George <jerrin.shaji-george@broadcom.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Joshua Hahn <joshua.hahnjy@gmail.com> Cc: Liam Howlett <liam.howlett@oracle.com> Cc: Madhavan Srinivasan <maddy@linux.ibm.com> Cc: Mathew Brost <matthew.brost@intel.com> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Miaohe Lin <linmiaohe@huawei.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Minchan Kim <minchan@kernel.org> Cc: Naoya Horiguchi <nao.horiguchi@gmail.com> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Peter Xu <peterx@redhat.com> Cc: Qi Zheng <zhengqi.arch@bytedance.com> Cc: Rakie Kim <rakie.kim@sk.com> Cc: Rik van Riel <riel@surriel.com> Cc: Sergey Senozhatsky <senozhatsky@chromium.org> Cc: Shakeel Butt <shakeel.butt@linux.dev> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com> Cc: xu xin <xu.xin16@zte.com.cn> Cc: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-07-13mm/hugetlb: remove prepare_hugepage_range()Peter Xu
Only mips and loongarch implemented this API, however what it does was checking against stack overflow for either len or addr. That's already done in arch's arch_get_unmapped_area*() functions, even though it may not be 100% identical checks. For example, for both of the architectures, there will be a trivial difference on how stack top was defined. The old code uses STACK_TOP which may be slightly smaller than TASK_SIZE on either of them, but the hope is that shouldn't be a problem. It means the whole API is pretty much obsolete at least now, remove it completely. Link: https://lkml.kernel.org/r/20250627160707.2124580-1-peterx@redhat.com Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Oscar Salvador <osalvador@suse.de> Acked-by: David Hildenbrand <david@redhat.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Huacai Chen <chenhuacai@kernel.org> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Muchun Song <muchun.song@linux.dev> Cc: Jann Horn <jannh@google.com> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-07-13um: Stop tracking stub's PID via userspace_pid[]Tiwei Bie
The PID of the stub process can be obtained from current_mm_id(). There is no need to track it via userspace_pid[]. Stop doing that to simplify the code. Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com> Link: https://patch.msgid.link/20250711065021.2535362-4-tiwei.bie@linux.dev Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-13um: Remove the pid parameter of handle_trap()Tiwei Bie
It's no longer used. Remove it. Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com> Link: https://patch.msgid.link/20250711065021.2535362-3-tiwei.bie@linux.dev Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-13um: Use err consistently in userspace()Tiwei Bie
Avoid declaring a new variable 'ret' inside the 'if (using_seccomp)' block, as the existing 'err' variable declared at the top of the function already serves the same purpose. Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com> Link: https://patch.msgid.link/20250711065021.2535362-2-tiwei.bie@linux.dev Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-13Merge tag 'x86_urgent_for_v6.16_rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Borislav Petkov: - Update Kirill's email address - Allow hugetlb PMD sharing only on 64-bit as it doesn't make a whole lotta sense on 32-bit - Add fixes for a misconfigured AMD Zen2 client which wasn't even supposed to run Linux * tag 'x86_urgent_for_v6.16_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: MAINTAINERS: Update Kirill Shutemov's email address for TDX x86/mm: Disable hugetlb page table sharing on 32-bit x86/CPU/AMD: Disable INVLPGB on Zen2 x86/rdrand: Disable RDSEED on AMD Cyan Skillfish
2025-07-13arm64: dts: imx8q: add camera ov5640 support for imx8qm-mek and imx8qxp-mekFrank Li
Add ov5640 overlay file for imx8qm-mek and imx8qxp-mek board. Camera can connect different CSI port. So use dts overlay file to handle these difference connect options. Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-07-12arm64: dts: altera: socfpga_stratix10: update internal oscillatorsMatthew Gerlach
Add the clock-frequency property to the cb_intosc_ls_clk and cb_intosc_hs_div2_clk device tree nodes. The f2s_free_clk is implemented by custom logic in the FPGA; so it should be disabled in the dtsi by default and enabled by a dts for a specific FPGA design on a specific board. Signed-off-by: Matthew Gerlach <matthew.gerlach@altera.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2025-07-12arm64: dts: socfpga: swvp: remove phy-addr in the GMAC nodeDinh Nguyen
This addresses this warning: socfpga_stratix10_swvp.dtb: ethernet@ff800000 (altr,socfpga-stmmac-a10-s10): 'phy-addr' does not match any of the regexes: '^pinctrl-[0-9]+$' Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2025-07-12arm64: dts: socfpga: swvp: remove cpu1-start-addrDinh Nguyen
The cpu1-start-addr property is only applicable to 32-bit SoCFPGA platforms. Removing this property will take care of warnings like this: socfpga_stratix10_swvp.dtb: sysmgr@ffd12000: cpu1-start-addr: False schema does not allow 4291846704 Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2025-07-12arm64: dts: socfpga: swvp: remove altr,modrst-offsetDinh Nguyen
'altr,modrst-offset' property is not applicable for arm64 SoCFPGA platforms. This will fix this dtbs_check warning: socfpga_stratix10_swvp.dtb: rstmgr@ffd11000: altr,modrst-offset: False schema does not allow 32 Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2025-07-12arm64: dts: socfpga: stratix10: fix dtbs_check for rstmgrDinh Nguyen
Add the default "altr,rst-mgr" to the rstmgr node on Stratix10. This fixes this warning: arch/arm64/boot/dts/altera:33:10 rstmgr@ffd11000 (altr,stratix10-rst-mgr): compatible: 'oneOf' conditional failed, one must be fixed: Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2025-07-12arm64: dts: socfpga: agilex: fix dtbs_check warning for f2s-free-clkDinh Nguyen
The f2s-free-clk requires a clock-frequency value. We put in an arbitrary value of 100 MHz for a constant. The true clock frequency would get generated in an FPGA design and the bootloader will populated in actual hardware designs. This fixes warning like this: arch/arm64/boot/dts/intel:34:8 4 f2s-free-clk (fixed-clock): 'clock-frequency' is a required property Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2025-07-12arm64: dts: allwinner: A523: Add SID controller nodeMikhail Kalashnikov
The SID controller should be compatible with A64 and others SoC with 0x200 offset. Signed-off-by: Mikhail Kalashnikov <iuncuim@gmail.com> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Link: https://patch.msgid.link/20250703151132.2642378-8-iuncuim@gmail.com [wens@csie.org: Fixed position of SID device node] Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-07-12arm64: dts: allwinner: a133-liontron-h-a133l: Add Ethernet supportPaul Kocialkowski
The Liontron H-A133L board features an Ethernet controller with a JLSemi JL1101 PHY. Its reset pin is tied to the PH12 GPIO. Note that the reset pin must be handled as a bus-wide reset GPIO in order to let the MDIO core properly reset it before trying to read its identification registers. There's no other device on the MDIO bus. The datasheet of the PHY mentions that the reset signal must be held for 1 ms to take effect. Make it 2 ms (and the same for post-delay) to be on the safe side without wasting too much time during boot. Signed-off-by: Paul Kocialkowski <paulk@sys-base.io> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Tested-by: Andre Przywara <andre.przywara@arm.com> Link: https://patch.msgid.link/20250707165155.581579-5-paulk@sys-base.io Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-07-12arm64: dts: allwinner: a100: Add EMAC supportPaul Kocialkowski
The Allwinner A100/A133 Ethernet MAC (EMAC) is compatible with the A64 one and needs access to the syscon register for control of the top-level integration of the unit. Note that there are two such controllers on the sun50iw10 die, which are the same unit with a different top-level syscon register offset. Signed-off-by: Paul Kocialkowski <paulk@sys-base.io> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Link: https://patch.msgid.link/20250707165155.581579-4-paulk@sys-base.io Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-07-12arm64: dts: allwinner: a100: Add pin definitions for RGMII/RMIIPaul Kocialkowski
The Allwinner A100/A133 supports both RGMII and RMII for its Ethernet MAC (EMAC) controller. Add corresponding pin definitions. Note that the sun50iw10 die actually includes two ethernet controllers, the second of which is rarely exposed to pins. Call the first controller "emac0" to distinguish it from the second that may be added later. Signed-off-by: Paul Kocialkowski <paulk@sys-base.io> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Link: https://patch.msgid.link/20250707165155.581579-3-paulk@sys-base.io Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-07-11x86/bugs: Print enabled attack vectorsDavid Kaplan
Print the status of enabled attack vectors and SMT mitigation status in the boot log for easier reporting and debugging. This information will also be available through sysfs. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-21-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for TSADavid Kaplan
Use attack vector controls to determine which TSA mitigation to use. [ bp: Simplify the condition in the select function for better readability. ] Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250709155844.3279471-1-david.kaplan@amd.com
2025-07-11x86/pti: Add attack vector controls for PTIDavid Kaplan
Disable PTI mitigation if user->kernel attack vector mitigations are disabled. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-20-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for ITSDavid Kaplan
Use attack vector controls to determine if ITS mitigation is required. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-19-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for SRSODavid Kaplan
Use attack vector controls to determine if SRSO mitigation is required. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-18-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for L1TFDavid Kaplan
Use attack vector controls to determine if L1TF mitigation is required. Disable SMT if cross-thread protection is desired. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-17-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for spectre_v2David Kaplan
Use attack vector controls to determine if spectre_v2 mitigation is required. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-16-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for BHIDavid Kaplan
Use attack vector controls to determine if BHI mitigation is required. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-15-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for spectre_v2_userDavid Kaplan
Use attack vector controls to determine if spectre_v2_user mitigation is required. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-14-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for retbleedDavid Kaplan
Use attack vector controls to determine if retbleed mitigation is required. Disable SMT if cross-thread protection is desired and STIBP is not available. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-13-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for spectre_v1David Kaplan
Use attack vector controls to determine if spectre_v1 mitigation is required. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-12-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for GDSDavid Kaplan
Use attack vector controls to determine if GDS mitigation is required. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-11-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for SRBDSDavid Kaplan
Use attack vector controls to determine if SRBDS mitigation is required. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-10-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for RFDSDavid Kaplan
Use attack vector controls to determine if RFDS mitigation is required. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-9-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for MMIODavid Kaplan
Use attack vectors controls to determine if MMIO mitigation is required. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-8-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for TAADavid Kaplan
Use attack vector controls to determine if TAA mitigation is required. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-7-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for MDSDavid Kaplan
Use attack vector controls to determine if MDS mitigation is required. The global mitigations=off command now simply disables all attack vectors so explicit checking of mitigations=off is no longer needed. If cross-thread attack mitigations are required, disable SMT. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-6-david.kaplan@amd.com
2025-07-11x86/bugs: Define attack vectors relevant for each bugDavid Kaplan
Add a function which defines which vulnerabilities should be mitigated based on the selected attack vector controls. The selections here are based on the individual characteristics of each vulnerability. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-5-david.kaplan@amd.com
2025-07-11x86/Kconfig: Add arch attack vector supportDavid Kaplan
ARCH_HAS_CPU_ATTACK_VECTORS should be set for architectures which implement the new attack-vector based controls for CPU mitigations. If an arch does not support attack-vector based controls then an attempt to use them results in a warning. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-4-david.kaplan@amd.com
2025-07-11ARM: tegra: chagall: Add embedded controller nodeSvyatoslav Ryhel
Add embedded controller node to Pegatron Chagall device-tree. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Link: https://lore.kernel.org/r/20250429061803.9581-5-clamor95@gmail.com Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-07-11ARM: tegra: Add device-tree for Asus Portable AiO P1801-TSvyatoslav Ryhel
Add a device-tree for the Asus Portable AiO P1801-T, which is a NVIDIA Tegra30-based 2-in-1 detachable tablet, originally running Android. The tablet was also sold together with a PC docking station as the Transformer AiO P1801. Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # P1801-T with dock Co-developed-by: Maxim Schwalm <maxim.schwalm@gmail.com> Signed-off-by: Maxim Schwalm <maxim.schwalm@gmail.com> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Link: https://lore.kernel.org/r/20250616073947.13675-3-clamor95@gmail.com Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-07-11arm64: tegra: Add p3971-0089+p3834-0008 supportThierry Reding
The P3971-0089+P3834-0008 is an engineering reference platform for the Tegra264 SoC. Link: https://lore.kernel.org/r/20250709231401.3767130-3-thierry.reding@gmail.com Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-07-11arm64: tegra: Add memory controller on Tegra264Thierry Reding
Link: https://lore.kernel.org/r/20250709231401.3767130-4-thierry.reding@gmail.com Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-07-11arm64: tegra: Add Tegra264 supportThierry Reding
Add basic support for the Tegra264 SoC, sufficient for booting into an initial ramdisk. Link: https://lore.kernel.org/r/20250709231401.3767130-2-thierry.reding@gmail.com Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-07-11arm64: dts: rockchip: describe the OV8858 user camera on PinePhone ProOlivier Benjamin
Add the description of the front/user camera (OV8858) on the PinePhone Pro to the device dts file. It receives commands over SCCB, an I2C-compatible protocol, at I2C address 0x36 and transmits data over CSI-MIPI. I confirmed this address experimentally. The pin control mapping was again extracted from the PinePhone Pro schematic v1.0 as well as the RK3399 datasheet revision 1.8. Table 2-3 in section 2.8 of the RK3399 datasheet contains the mapping of IO functions for the SoC pins. Page 52 shows GPIO1_A4, page 54 shows GPIO2_B4. For the reset (RESET) signal: page 11 quadrant D2 | p.18 q.B3-4 | p.18 q.C2 RK3399_E.R28 -> GPIO1_A4 -> Camera2_RST -> MIPI_RST1 -> OV8858.12 For the powerdown (PWDN) signal: page 9 quadrants D4-5 | p.18 q.B2 RK3399_L.F31 -> GPIO2_B4 -> DVP_PDN0_H -> OV8858.14 Helped-by: Dragan Simic <dsimic@manjaro.org> Co-developed-by: Ondrej Jirman <megi@xff.cz> Signed-off-by: Ondrej Jirman <megi@xff.cz> Signed-off-by: Olivier Benjamin <olivier.benjamin@bootlin.com> Link: https://lore.kernel.org/r/20250620-camera-v4-4-0201a8ed5fae@bootlin.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-07-11arm64: dts: rockchip: describe I2c Bus 1 and IMX258 world camera on ↵Olivier Benjamin
PinePhone Pro Add the description of the rear/world camera (IMX258) on the PinePhone Pro to the device dts file. It receives commands on the I2C Bus 1 at address 0x1a and transmits data over CSI-MIPI. The I2C address for IMX258 can be found in the IMX258-0AQH5 Software Reference Manual, page 24, section 2.3.1: 0b0011010 = 0x1a. Section 3 indicates the module has 4 pairs of data lines. While 4-lane mode is nominal, 2-lane mode should also be supported. The pin muxing info was extracted from the PinePhone Pro schematic v1.0 as well as the RK3399 datasheet revision 1.8. Table 2-3 in section 2.8 of the RK3399 datasheet contains the mapping of IO functions for the SoC pins. Page 52 shows GPIO1_A0, page 54 shows GPIO2_D4. For I2C power, the PinePhone Pro schematic page 11 quadrants A4 and A5: RK3399_J.AA8 and RK3399_J.Y8 get power from vcaa1v8_codec, so turn it on The IMX258 also uses the following regulators, expected by its driver: - vana (2.8V analog), called AVDD2V8_DVP on P.18 q.C1 and derived from VCC1V8_S3 on P.13 q.B2 - vdig (1.2V digital core), called DVDD_DVP on P.18 q.C1 and shown on P.18 q.D3 to be equivalent to VCC1V2_DVP derived from VCC3V3_SYS on P.13 q.B3. Note that this regulator's voltage is inconsistently labeled either 1.2V or 1.5V RK3399_J.AG1 is GPIO4_A1/I2C1_SDA, RK3399_J.Y6 is GPIO4_A2/I2C1_SCL This is the default pinctrl "i2c1_xfer" for i2c1 from rk3399-base. For the reset (RESET) signal: page 11 quadrant D2 | p.18 q.C3-4 | p.18 q.C2 RK3399_E.R25 -> GPIO1_A0 -> Camera_RST -> MIPI_RST0 -> IMX258.12 For the powerdown (PWDN) signal: page 11 quadrants B4-5 | p.18 q.C2 RK3399_G.AF8 -> GPIO2_D4 -> DVP_PDN1_H -> IMX258.14 Helped-by: Dragan Simic <dsimic@manjaro.org> Co-developed-by: Ondrej Jirman <megi@xff.cz> Signed-off-by: Ondrej Jirman <megi@xff.cz> Signed-off-by: Olivier Benjamin <olivier.benjamin@bootlin.com> Link: https://lore.kernel.org/r/20250620-camera-v4-3-0201a8ed5fae@bootlin.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-07-11arm64: dts: rockchip: Fix pinctrl node names for RK3528Jonas Karlman
Following warnings can be observed with CHECK_DTBS=y for the RK3528: rk3528-pinctrl.dtsi:101.36-105.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym0-led_dpx: Character '_' not recommended in node name rk3528-pinctrl.dtsi:108.38-112.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym0-led_link: Character '_' not recommended in node name rk3528-pinctrl.dtsi:115.36-119.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym0-led_spd: Character '_' not recommended in node name rk3528-pinctrl.dtsi:122.36-126.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym1-led_dpx: Character '_' not recommended in node name rk3528-pinctrl.dtsi:129.38-133.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym1-led_link: Character '_' not recommended in node name rk3528-pinctrl.dtsi:136.36-140.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym1-led_spd: Character '_' not recommended in node name rk3528-pinctrl.dtsi:782.32-790.5: Warning (node_name_chars_strict): /pinctrl/rgmii/rgmii-rx_bus2: Character '_' not recommended in node name rk3528-pinctrl.dtsi:793.32-801.5: Warning (node_name_chars_strict): /pinctrl/rgmii/rgmii-tx_bus2: Character '_' not recommended in node name rk3528-pinctrl.dtsi:804.36-810.5: Warning (node_name_chars_strict): /pinctrl/rgmii/rgmii-rgmii_clk: Character '_' not recommended in node name rk3528-pinctrl.dtsi:813.36-823.5: Warning (node_name_chars_strict): /pinctrl/rgmii/rgmii-rgmii_bus: Character '_' not recommended in node name Rename the affected nodes to fix these warnings. Fixes: a31fad19ae39 ("arm64: dts: rockchip: Add pinctrl and gpio nodes for RK3528") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Link: https://lore.kernel.org/r/20250621113859.2146400-1-jonas@kwiboo.se Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-07-11arm64: dts: rockchip: Add FriendlyElec NanoPi M5 supportJohn Clark
Add device tree for FriendlyElec NanoPi M5 with Rockchip RK3576 SoC (4x Cortex-A72, 4x Cortex-A53, Mali-G52 MC3 GPU, 6 TOPS NPU). Enables basic booting and connectivity. Supported features: - RK3576 SoC - 4GB LPDDR4X or 8GB/16GB LPDDR5 - 16MB SPI Nor Flash - 2x 1Gbps Ethernet - 2x USB 3.2 Gen 1 Type-A ports - M.2 M-Key PCIe 2.1 x1 NVMe support - M.2 E-Key SDIO connector - microSD UHS-I - HDMI 1.4/2.0 (up to 4096x2304@60Hz) - 30-pin GPIO (2x SPI, 4x UART, 3x I2C, 5x PWM, 20x GPIO) - Debug UART - RTC with HYM8563TS - Power via USB-C (PD, 6V~20V) Signed-off-by: John Clark <inindev@gmail.com> Link: https://lore.kernel.org/r/20250628143229.74460-3-inindev@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-07-11arm64: dts: rockchip: force PMIC reset behavior to restart PMU on RK3588 TigerQuentin Schulz
The bootloader for RK3588 Tiger currently forces the PMIC reset behavior (stored in RST_FUN bitfield in register SYS_CFG3 of the PMIC) to 0b1X which is incorrect for our devices. It is required to restart the PMU as otherwise the companion microcontroller cannot detect the PMIC (and by extension the full product and main SoC) being rebooted which is an issue as that is used to reset a few things like the PWM beeper and watchdogs. Let's add the new rockchip,reset-mode property to make sure the PMIC reset behavior is the expected one. Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Link: https://lore.kernel.org/r/20250627-rk8xx-rst-fun-v4-5-ce05d041b45f@cherry.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-07-11arm64: dts: rockchip: force PMIC reset behavior to restart PMU on RK3588 JaguarQuentin Schulz
The bootloader for RK3588 Jaguar currently forces the PMIC reset behavior (stored in RST_FUN bitfield in register SYS_CFG3 of the PMIC) to 0b1X which is incorrect for our devices. It is required to restart the PMU as otherwise the companion microcontroller cannot detect the PMIC (and by extension the full product and main SoC) being rebooted which is an issue as that is used to reset a few things like the PWM beeper and watchdogs. Let's add the new rockchip,reset-mode property to make sure the PMIC reset behavior is the expected one. Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Link: https://lore.kernel.org/r/20250627-rk8xx-rst-fun-v4-4-ce05d041b45f@cherry.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-07-11arm64: dts: rockchip: add header for RK8XX PMIC constantsQuentin Schulz
To make it easier to read the device tree, let's add constants for the rockchip,reset-mode property values that are currently only applicable to RK806 PMIC. Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> [dt-maintainers did not consider this part of the binding, so we're keeping the header in the devicetree directory] Link: https://lore.kernel.org/r/20250627-rk8xx-rst-fun-v4-3-ce05d041b45f@cherry.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-07-11arm64: dts: rockchip: add HDMI audio on ROCK 4DNicolas Frattaroli
Much like the Sige5, the ROCK 4D also has an HDMI port, so is capable of providing HDMI audio output as well. Enable the SoC's hdmi_sound card, and also enable the SoC audio controller (sai6) that feeds into it. Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Tested-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20250630-rock4d-audio-v1-4-0b3c8e8fda9c@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>