summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2026-02-26arm64: Optimize __READ_ONCE() with CONFIG_LTO=yMarco Elver1-4/+14
Rework arm64 LTO __READ_ONCE() to improve code generation as follows: 1. Replace _Generic-based __unqual_scalar_typeof() with more complete __rwonce_typeof_unqual(). This strips qualifiers from all types, not just integer types, which is required to be able to assign (must be non-const) to __u.__val in the non-atomic case (required for #2). One subtle point here is that non-integer types of __val could be const or volatile within the union with the old __unqual_scalar_typeof(), if the passed variable is const or volatile. This would then result in a forced load from the stack if __u.__val is volatile; in the case of const, it does look odd if the underlying storage changes, but the compiler is told said member is "const" -- it smells like UB. 2. Eliminate the atomic flag and ternary conditional expression. Move the fallback volatile load into the default case of the switch, ensuring __u is unconditionally initialized across all paths. The statement expression now unconditionally returns __u.__val. This refactoring appears to help the compiler improve (or fix) code generation. With a defconfig + LTO + debug options builds, we observe different codegen for the following functions: btrfs_reclaim_sweep (708 -> 1032 bytes) btrfs_sinfo_bg_reclaim_threshold_store (200 -> 204 bytes) check_mem_access (3652 -> 3692 bytes) [inlined bpf_map_is_rdonly] console_flush_all (1268 -> 1264 bytes) console_lock_spinning_disable_and_check (180 -> 176 bytes) igb_add_filter (640 -> 636 bytes) igb_config_tx_modes (2404 -> 2400 bytes) kvm_vcpu_on_spin (480 -> 476 bytes) map_freeze (376 -> 380 bytes) netlink_bind (1664 -> 1656 bytes) nmi_cpu_backtrace (404 -> 400 bytes) set_rps_cpu (516 -> 520 bytes) swap_cluster_readahead (944 -> 932 bytes) tcp_accecn_third_ack (328 -> 336 bytes) tcp_create_openreq_child (1764 -> 1772 bytes) tcp_data_queue (5784 -> 5892 bytes) tcp_ecn_rcv_synack (620 -> 628 bytes) xen_manage_runstate_time (944 -> 896 bytes) xen_steal_clock (340 -> 296 bytes) Increase of some functions are due to more aggressive inlining due to better codegen (in this build, e.g. bpf_map_is_rdonly is no longer present due to being inlined completely). NOTE: The return-value-of-function-drops-qualifiers hack was first suggested by Al Viro in [1], which notes some of its limitations which make it unsuitable for a general __unqual_scalar_typeof() replacement. Notably, array types are not supported, and GCC 8.1-8.3 still fail. Why should we use it here? READ_ONCE() does not support reading whole arrays, and the GCC version problem only affects 3 minor releases of a very ancient still-supported GCC version; not only that, this arm64 READ_ONCE() version is currently only activated by LTO builds, which to-date are *only supported by Clang*! Link: https://lore.kernel.org/all/20260111182010.GH3634291@ZenIV/ [1] Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-02-26x86: rtc: Drop PNP device checkRafael J. Wysocki1-16/+1
Previous changes effectively prevented PNP devices from being created for the CMOS RTC on x86 with ACPI. Although in principle a CMOS RTC PNP device may exist on an x86 system without ACPI (that is, an x86 system where there is no ACPI at all, not one booted with ACPI disabled), such systems were there in the field ~30 years ago and most likely they would not be able to run a contemporary Linux kernel. For the above reasons, drop the PNP device check from add_rtc_cmos(). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> # x86 Link: https://patch.msgid.link/8660687.T7Z3S40VBb@rafael.j.wysocki
2026-02-26ACPI: x86: cmos_rtc: Create a CMOS RTC platform deviceRafael J. Wysocki1-0/+4
Make the CMOS RTC ACPI scan handler create a platform device that will be used subsequently by rtc-cmos for driver binding on x86 systems with ACPI and update add_rtc_cmos() to skip registering a fallback platform device for the CMOS RTC when the above one has been registered. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> # x86 Link: https://patch.msgid.link/1962427.tdWV9SEqCh@rafael.j.wysocki
2026-02-26riscv: dts: spacemit: Update PMIC supply properties for BPI-F3 and JupiterGuodong Xu2-4/+20
Use per-regulator supply names in pmic "spacemit,p1" node to specify each board's power tree topology and match the updated dt-binding. Signed-off-by: Guodong Xu <guodong@riscstar.com> Reviewed-by: Alex Elder <elder@riscstar.com> Link: https://lore.kernel.org/r/20260206-spacemit-p1-v4-3-8f695d93811e@riscstar.com Signed-off-by: Yixun Lan <dlan@kernel.org>
2026-02-26riscv: dts: spacemit: pcie: fix missing power regulatorYixun Lan1-0/+2
The PCIe port require 3.3v power regulator for device to work properly, So explicitly add it to fix the DT warning: arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dtb: pcie@ca400000 (spacemit,k1-pcie): pcie@0: 'vpcie3v3-supply' is a required property from schema $id: http://devicetree.org/schemas/pci/spacemit,k1-pcie-host.yaml Fixes: 0be016a4b5d1 ("riscv: dts: spacemit: PCIe and PHY-related updates") Reported-by: Conor Dooley <conor@kernel.org> Link: https://lore.kernel.org/r/20260226-k1-pcie-fix-pwr-v1-1-94b493cd27e5@kernel.org Signed-off-by: Yixun Lan <dlan@kernel.org>
2026-02-26arm64: dts: exynos: add initial support for Samsung Galaxy J7 (2016)Rayan Marzouk2-0/+498
Add initial devicetree support for Samsung Galaxy J7 (2016) (codename: j7xelte), an Exynos7870 device. Signed-off-by: Rayan Marzouk <rayanmarzouk743@gmail.com> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Link: https://patch.msgid.link/20260125-exynos7870-j7xelte-v1-2-5cacc3042c42@disroot.org Link: https://lore.kernel.org/r/DGNRDQ5886K7.3NSLKILM1GDWR@disroot.org/ Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-02-26x86/virt/tdx: Print TDX module version during initVishal Verma1-0/+6
It is useful to print the TDX module version in dmesg logs. This is currently the only way to determine the module version from the host. It also creates a record for any future problems being investigated. This was also requested in [1]. Include the version in the log messages during init, e.g.: virt/tdx: TDX module version: 1.5.24 virt/tdx: 1034220 KB allocated for PAMT virt/tdx: module initialized Print the version in get_tdx_sys_info(), right after the version metadata is read, which makes it available even if there are subsequent initialization failures. Based on a patch by Kai Huang <kai.huang@intel.com> [2] Signed-off-by: Vishal Verma <vishal.l.verma@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Chao Gao <chao.gao@intel.com> Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com> Reviewed-by: Kiryl Shutsemau <kas@kernel.org> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Reviewed-by: Kai Huang <kai.huang@intel.com> Link: https://lore.kernel.org/all/CAGtprH8eXwi-TcH2+-Fo5YdbEwGmgLBh9ggcDvd6N=bsKEJ_WQ@mail.gmail.com/ # [1] Link: https://lore.kernel.org/all/6b5553756f56a8e3222bfc36d0bdb3e5192137b7.1731318868.git.kai.huang@intel.com # [2] Link: https://patch.msgid.link/20260109-tdx_print_module_version-v2-2-e10e4ca5b450@intel.com
2026-02-26x86/virt/tdx: Retrieve TDX module versionChao Gao2-0/+23
Each TDX module has several bits of metadata about which specific TDX module it is. The primary bit of info is the version, which has an x.y.z format. These represent the major version, minor version, and update version respectively. Knowing the running TDX Module version is valuable for bug reporting and debugging. Note that the module does expose other pieces of version-related metadata, such as build number and date. Those aren't retrieved for now, that can be added if needed in the future. Retrieve the TDX Module version using the existing metadata reading interface. Later changes will expose this information. The metadata reading interfaces have existed for quite some time, so this will work with older versions of the TDX module as well - i.e. this isn't a new interface. As a side note, the global metadata reading code was originally set up to be auto-generated from a JSON definition [1]. However, later [2] this was found to be unsustainable, and the autogeneration approach was dropped in favor of just manually adding fields as needed (e.g. as in this patch). Signed-off-by: Chao Gao <chao.gao@intel.com> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Kiryl Shutsemau <kas@kernel.org> Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Kai Huang <kai.huang@intel.com> Link: https://lore.kernel.org/kvm/CABgObfYXUxqQV_FoxKjC8U3t5DnyM45nz5DpTxYZv2x_uFK_Kw@mail.gmail.com/ # [1] Link: https://lore.kernel.org/all/1e7bcbad-eb26-44b7-97ca-88ab53467212@intel.com/ # [2] Link: https://patch.msgid.link/20260109-tdx_print_module_version-v2-1-e10e4ca5b450@intel.com
2026-02-26arm64: tlb: Optimize ARM64_WORKAROUND_REPEAT_TLBIMark Rutland6-36/+47
The ARM64_WORKAROUND_REPEAT_TLBI workaround is used to mitigate several errata where broadcast TLBI;DSB sequences don't provide all the architecturally required synchronization. The workaround performs more work than necessary, and can have significant overhead. This patch optimizes the workaround, as explained below. The workaround was originally added for Qualcomm Falkor erratum 1009 in commit: d9ff80f83ecb ("arm64: Work around Falkor erratum 1009") As noted in the message for that commit, the workaround is applied even in cases where it is not strictly necessary. The workaround was later reused without changes for: * Arm Cortex-A76 erratum #1286807 SDEN v33: https://developer.arm.com/documentation/SDEN-885749/33-0/ * Arm Cortex-A55 erratum #2441007 SDEN v16: https://developer.arm.com/documentation/SDEN-859338/1600/ * Arm Cortex-A510 erratum #2441009 SDEN v19: https://developer.arm.com/documentation/SDEN-1873351/1900/ The important details to note are as follows: 1. All relevant errata only affect the ordering and/or completion of memory accesses which have been translated by an invalidated TLB entry. The actual invalidation of TLB entries is unaffected. 2. The existing workaround is applied to both broadcast and local TLB invalidation, whereas for all relevant errata it is only necessary to apply a workaround for broadcast invalidation. 3. The existing workaround replaces every TLBI with a TLBI;DSB;TLBI sequence, whereas for all relevant errata it is only necessary to execute a single additional TLBI;DSB sequence after any number of TLBIs are completed by a DSB. For example, for a sequence of batched TLBIs: TLBI <op1>[, <arg1>] TLBI <op2>[, <arg2>] TLBI <op3>[, <arg3>] DSB ISH ... the existing workaround will expand this to: TLBI <op1>[, <arg1>] DSB ISH // additional TLBI <op1>[, <arg1>] // additional TLBI <op2>[, <arg2>] DSB ISH // additional TLBI <op2>[, <arg2>] // additional TLBI <op3>[, <arg3>] DSB ISH // additional TLBI <op3>[, <arg3>] // additional DSB ISH ... whereas it is sufficient to have: TLBI <op1>[, <arg1>] TLBI <op2>[, <arg2>] TLBI <op3>[, <arg3>] DSB ISH TLBI <opX>[, <argX>] // additional DSB ISH // additional Using a single additional TBLI and DSB at the end of the sequence can have significantly lower overhead as each DSB which completes a TLBI must synchronize with other PEs in the system, with potential performance effects both locally and system-wide. 4. The existing workaround repeats each specific TLBI operation, whereas for all relevant errata it is sufficient for the additional TLBI to use *any* operation which will be broadcast, regardless of which translation regime or stage of translation the operation applies to. For example, for a single TLBI: TLBI ALLE2IS DSB ISH ... the existing workaround will expand this to: TLBI ALLE2IS DSB ISH TLBI ALLE2IS // additional DSB ISH // additional ... whereas it is sufficient to have: TLBI ALLE2IS DSB ISH TLBI VALE1IS, XZR // additional DSB ISH // additional As the additional TLBI doesn't have to match a specific earlier TLBI, the additional TLBI can be implemented in separate code, with no memory of the earlier TLBIs. The additional TLBI can also use a cheaper TLBI operation. 5. The existing workaround is applied to both Stage-1 and Stage-2 TLB invalidation, whereas for all relevant errata it is only necessary to apply a workaround for Stage-1 invalidation. Architecturally, TLBI operations which invalidate only Stage-2 information (e.g. IPAS2E1IS) are not required to invalidate TLB entries which combine information from Stage-1 and Stage-2 translation table entries, and consequently may not complete memory accesses translated by those combined entries. In these cases, completion of memory accesses is only guaranteed after subsequent invalidation of Stage-1 information (e.g. VMALLE1IS). Taking the above points into account, this patch reworks the workaround logic to reduce overhead: * New __tlbi_sync_s1ish() and __tlbi_sync_s1ish_hyp() functions are added and used in place of any dsb(ish) which is used to complete broadcast Stage-1 TLB maintenance. When the ARM64_WORKAROUND_REPEAT_TLBI workaround is enabled, these helpers will execute an additional TLBI;DSB sequence. For consistency, it might make sense to add __tlbi_sync_*() helpers for local and stage 2 maintenance. For now I've left those with open-coded dsb() to keep the diff small. * The duplication of TLBIs in __TLBI_0() and __TLBI_1() is removed. This is no longer needed as the necessary synchronization will happen in __tlbi_sync_s1ish() or __tlbi_sync_s1ish_hyp(). * The additional TLBI operation is chosen to have minimal impact: - __tlbi_sync_s1ish() uses "TLBI VALE1IS, XZR". This is only used at EL1 or at EL2 with {E2H,TGE}=={1,1}, where it will target an unused entry for the reserved ASID in the kernel's own translation regime, and have no adverse affect. - __tlbi_sync_s1ish_hyp() uses "TLBI VALE2IS, XZR". This is only used in hyp code, where it will target an unused entry in the hyp code's TTBR0 mapping, and should have no adverse effect. * As __TLBI_0() and __TLBI_1() no longer replace each TLBI with a TLBI;DSB;TLBI sequence, batching TLBIs is worthwhile, and there's no need for arch_tlbbatch_should_defer() to consider ARM64_WORKAROUND_REPEAT_TLBI. When building defconfig with GCC 15.1.0, compared to v6.19-rc1, this patch saves ~1KiB of text, makes the vmlinux ~42KiB smaller, and makes the resulting Image 64KiB smaller: | [mark@lakrids:~/src/linux]% size vmlinux-* | text data bss dec hex filename | 21179831 19660919 708216 41548966 279fca6 vmlinux-after | 21181075 19660903 708216 41550194 27a0172 vmlinux-before | [mark@lakrids:~/src/linux]% ls -l vmlinux-* | -rwxr-xr-x 1 mark mark 157771472 Feb 4 12:05 vmlinux-after | -rwxr-xr-x 1 mark mark 157815432 Feb 4 12:05 vmlinux-before | [mark@lakrids:~/src/linux]% ls -l Image-* | -rw-r--r-- 1 mark mark 41007616 Feb 4 12:05 Image-after | -rw-r--r-- 1 mark mark 41073152 Feb 4 12:05 Image-before Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Oliver Upton <oupton@kernel.org> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2026-02-26arm64: tlb: Allow XZR argument to TLBI opsMark Rutland1-3/+3
The TLBI instruction accepts XZR as a register argument, and for TLBI operations with a register argument, there is no functional difference between using XZR or another GPR which contains zeroes. Operations without a register argument are encoded as if XZR were used. Allow the __TLBI_1() macro to use XZR when a register argument is all zeroes. Today this only results in a trivial code saving in __do_compat_cache_op()'s workaround for Neoverse-N1 erratum #1542419. In subsequent patches this pattern will be used more generally. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Oliver Upton <oupton@kernel.org> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2026-02-25arm64: gcs: Honour mprotect(PROT_NONE) on shadow stack mappingsCatalin Marinas1-1/+5
vm_get_page_prot() short-circuits the protection_map[] lookup for a VM_SHADOW_STACK mapping since it uses a different PIE index from the typical read/write/exec permissions. However, the side effect is that it also ignores mprotect(PROT_NONE) by creating an accessible PTE. Special-case the !(vm_flags & VM_ACCESS_FLAGS) flags to use the protection_map[VM_NONE] permissions instead. No GCS attributes are required for an inaccessible PTE. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Fixes: 6497b66ba694 ("arm64/mm: Map pages for guarded control stack") Cc: stable@vger.kernel.org Cc: Mark Brown <broonie@kernel.org> Cc: Will Deacon <will@kernel.org> Cc: David Hildenbrand <david@kernel.org> Reviewed-by: David Hildenbrand (Arm) <david@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2026-02-25arm64: gcs: Do not set PTE_SHARED on GCS mappings if FEAT_LPA2 is enabledCatalin Marinas2-5/+6
When FEAT_LPA2 is enabled, bits 8-9 of the PTE replace the shareability attribute with bits 50-51 of the output address. The _PAGE_GCS{,_RO} definitions include the PTE_SHARED bits as 0b11 (this matches the other _PAGE_* definitions) but using this macro directly leads to the following panic when enabling GCS on a system/model with LPA2: Unable to handle kernel paging request at virtual address fffff1ffc32d8008 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 52-bit VAs, pgdp=0000000060f4d000 [fffff1ffc32d8008] pgd=100000006184b003, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 0 UID: 0 PID: 513 Comm: gcs_write_fault Tainted: G M 7.0.0-rc1 #1 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: QEMU QEMU Virtual Machine, BIOS 2025.02-8+deb13u1 11/08/2025 pstate: 03402005 (nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : zap_huge_pmd+0x168/0x468 lr : zap_huge_pmd+0x2c/0x468 sp : ffff800080beb660 x29: ffff800080beb660 x28: fff00000c2058180 x27: ffff800080beb898 x26: fff00000c2058180 x25: ffff800080beb820 x24: 00c800010b600f41 x23: ffffc1ffc30af1a8 x22: fff00000c2058180 x21: 0000ffff8dc00000 x20: fff00000c2bc6370 x19: ffff800080beb898 x18: ffff800080bebb60 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000007 x14: 000000000000000a x13: 0000aaaacbbbffff x12: 0000000000000000 x11: 0000ffff8ddfffff x10: 00000000000001fe x9 : 0000ffff8ddfffff x8 : 0000ffff8de00000 x7 : 0000ffff8da00000 x6 : fff00000c2bc6370 x5 : 0000ffff8da00000 x4 : 000000010b600000 x3 : ffffc1ffc0000000 x2 : fff00000c2058180 x1 : fffff1ffc32d8000 x0 : 000000c00010b600 Call trace: zap_huge_pmd+0x168/0x468 (P) unmap_page_range+0xd70/0x1560 unmap_single_vma+0x48/0x80 unmap_vmas+0x90/0x180 unmap_region+0x88/0xe4 vms_complete_munmap_vmas+0xf8/0x1e0 do_vmi_align_munmap+0x158/0x180 do_vmi_munmap+0xac/0x160 __vm_munmap+0xb0/0x138 vm_munmap+0x14/0x20 gcs_free+0x70/0x80 mm_release+0x1c/0xc8 exit_mm_release+0x28/0x38 do_exit+0x190/0x8ec do_group_exit+0x34/0x90 get_signal+0x794/0x858 arch_do_signal_or_restart+0x11c/0x3e0 exit_to_user_mode_loop+0x10c/0x17c el0_da+0x8c/0x9c el0t_64_sync_handler+0xd0/0xf0 el0t_64_sync+0x198/0x19c Code: aa1603e2 d34cfc00 cb813001 8b011861 (f9400420) Similarly to how the kernel handles protection_map[], use a gcs_page_prot variable to store the protection bits and clear PTE_SHARED if LPA2 is enabled. Also remove the unused PAGE_GCS{,_RO} macros. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Fixes: 6497b66ba694 ("arm64/mm: Map pages for guarded control stack") Reported-by: Emanuele Rocca <emanuele.rocca@arm.com> Cc: stable@vger.kernel.org Cc: Mark Brown <broonie@kernel.org> Cc: Will Deacon <will@kernel.org> Reviewed-by: David Hildenbrand (Arm) <david@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2026-02-25arm64: io: Extract user memory type in ioremap_prot()Will Deacon1-2/+15
The only caller of ioremap_prot() outside of the generic ioremap() implementation is generic_access_phys(), which passes a 'pgprot_t' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprot_t' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from ioremap_prot() which faults when accessed from the kernel on systems with PAN: | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 | ... | Call trace: | __memcpy_fromio+0x80/0xf8 | generic_access_phys+0x20c/0x2b8 | __access_remote_vm+0x46c/0x5b8 | access_remote_vm+0x18/0x30 | environ_read+0x238/0x3e8 | vfs_read+0xe4/0x2b0 | ksys_read+0xcc/0x178 | __arm64_sys_read+0x4c/0x68 Extract only the memory type from the user 'pgprot_t' in ioremap_prot() and assert that we're being passed a user mapping, to protect us against any changes in future that may require additional handling. To avoid falsely flagging users of ioremap(), provide our own ioremap() macro which simply wraps __ioremap_prot(). Cc: Zeng Heng <zengheng4@huawei.com> Cc: Jinjiang Tu <tujinjiang@huawei.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Fixes: 893dea9ccd08 ("arm64: Add HAVE_IOREMAP_PROT support") Reported-by: Jinjiang Tu <tujinjiang@huawei.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-02-25arm64: io: Rename ioremap_prot() to __ioremap_prot()Will Deacon3-9/+10
Rename our ioremap_prot() implementation to __ioremap_prot() and convert all arch-internal callers over to the new function. ioremap_prot() remains as a #define to __ioremap_prot() for generic_access_phys() and will be subsequently extended to handle user permissions in 'prot'. Cc: Zeng Heng <zengheng4@huawei.com> Cc: Jinjiang Tu <tujinjiang@huawei.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-02-25s390/pfault: Fix virtual vs physical address confusionAlexander Gordeev1-2/+2
When Linux is running as guest, runs a user space process and the user space process accesses a page that the host has paged out, the guest gets a pfault interrupt and schedules a different process. Without this mechanism the host would have to suspend the whole virtual CPU until the page has been paged in. To setup the pfault interrupt the real address of parameter list should be passed to DIAGNOSE 0x258, but a virtual address is passed instead. That has a performance impact, since the pfault setup never succeeds, the interrupt is never delivered to a guest and the whole virtual CPU is suspended as result. Cc: stable@vger.kernel.org Fixes: c98d2ecae08f ("s390/mm: Uncouple physical vs virtual address spaces") Reported-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-02-25s390/kexec: Disable stack protector in s390_reset_system()Vasily Gorbik1-1/+1
s390_reset_system() calls set_prefix(0), which switches back to the absolute lowcore. At that point the stack protector canary no longer matches the canary from the lowcore the function was entered with, so the stack check fails. Mark s390_reset_system() __no_stack_protector. This is safe here since its callers (__do_machine_kdump() and __do_machine_kexec()) are effectively no-return and fall back to disabled_wait() on failure. Fixes: f5730d44e05e ("s390: Add stackprotector support") Reported-by: Nikita Dubrovskii <nikita@linux.ibm.com> Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Acked-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-02-25s390/idle: Remove psw_idle() prototypeHeiko Carstens1-2/+0
psw_idle() does not exist anymore. Remove its prototype. Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-02-25s390/vtime: Use lockdep_assert_irqs_disabled() instead of BUG_ON()Heiko Carstens1-2/+1
Use lockdep_assert_irqs_disabled() instead of BUG_ON(). This avoids crashing the kernel, and generates better code if CONFIG_PROVE_LOCKING is disabled. Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-02-25s390/vtime: Use __this_cpu_read() / get rid of READ_ONCE()Heiko Carstens1-14/+7
do_account_vtime() runs always with interrupts disabled, therefore use __this_cpu_read() instead of this_cpu_read() to get rid of a pointless preempt_disable() / preempt_enable() pair. Also there are no concurrent writers to the cpu time accounting fields in lowcore. Therefore get rid of READ_ONCE() usages. Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-02-25s390/irq/idle: Remove psw bits earlyHeiko Carstens1-8/+6
Remove wait, io, external interrupt bits early in do_io_irq()/do_ext_irq() when previous context was idle. This saves one conditional branch and is closer to the original old assembly code. Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-02-25s390/idle: Inline update_timer_idle()Heiko Carstens4-35/+38
Inline update_timer_idle() again to avoid an extra function call. This way the generated code is close to old assembler version again. Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-02-25s390/idle: Slightly optimize idle time accountingHeiko Carstens1-7/+8
Slightly optimize account_idle_time_irq() and update_timer_idle(): - Use fast single instruction __atomic64() primitives to update per cpu idle_time and idle_count, instead of READ_ONCE() / WRITE_ONCE() pairs - stcctm() is an inline assembly with a full memory barrier. This leads to a not necessary extra dereference of smp_cpu_mtid in update_timer_idle(). Avoid this and read smp_cpu_mtid into a variable - Use __this_cpu_add() instead of this_cpu_add() to avoid disabling / enabling of preemption several times in a loop in update_timer_idle(). Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-02-25s390/idle: Add comment for non obvious codeHeiko Carstens1-0/+9
Add a comment to update_timer_idle() which describes why wall time (not steal time) is added to steal_timer. This is not obvious and was reported by Frederic Weisbecker. Reported-by: Frederic Weisbecker <frederic@kernel.org> Closes: https://lore.kernel.org/all/aXEVM-04lj0lntMr@localhost.localdomain/ Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-02-25s390/vtime: Fix virtual timer forwardingHeiko Carstens1-16/+2
Since delayed accounting of system time [1] the virtual timer is forwarded by do_account_vtime() but also vtime_account_kernel(), vtime_account_softirq(), and vtime_account_hardirq(). This leads to double accounting of system, guest, softirq, and hardirq time. Remove accounting from the vtime_account*() family to restore old behavior. There is only one user of the vtimer interface, which might explain why nobody noticed this so far. Fixes: b7394a5f4ce9 ("sched/cputime, s390: Implement delayed accounting of system time") [1] Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-02-25s390/idle: Fix cpu idle exit cpu time accountingHeiko Carstens3-6/+18
With the conversion to generic entry [1] cpu idle exit cpu time accounting was converted from assembly to C. This introduced an reversed order of cpu time accounting. On cpu idle exit the current accounting happens with the following call chain: -> do_io_irq()/do_ext_irq() -> irq_enter_rcu() -> account_hardirq_enter() -> vtime_account_irq() -> vtime_account_kernel() vtime_account_kernel() accounts the passed cpu time since last_update_timer as system time, and updates last_update_timer to the current cpu timer value. However the subsequent call of -> account_idle_time_irq() will incorrectly subtract passed cpu time from timer_idle_enter to the updated last_update_timer value from system_timer. Then last_update_timer is updated to a sys_enter_timer, which means that last_update_timer goes back in time. Subsequently account_hardirq_exit() will account too much cpu time as hardirq time. The sum of all accounted cpu times is still correct, however some cpu time which was previously accounted as system time is now accounted as hardirq time, plus there is the oddity that last_update_timer goes back in time. Restore previous behavior by extracting cpu time accounting code from account_idle_time_irq() into a new update_timer_idle() function and call it before irq_enter_rcu(). Fixes: 56e62a737028 ("s390: convert to generic entry") [1] Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-02-25arm64: dts: qcom: x1-vivobook-s15: add Purwa-compatible device treeJens Glathe2-0/+45
The ASUS Vivobook S15 (S5507) [1] is available with Hamoa and Purwa SoC. Add the Purwa-based device tree. [1]: https://www.asus.com/de/laptops/for-home/vivobook/asus-vivobook-s-15-s5507/techspec/ Tested-by: Colin K. Williams <colin@li-nk.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260214-b4-vivobook-v3-4-3c88065bbf77@oldschoolsolutions.biz Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-02-25arm64: dts: qcom: x1-vivobook-s15: create a common dtsi for Hamoa and Purwa ↵Jens Glathe2-1345/+1363
variants The Asus VivoBook S15 S5507QA is sold with x1e-78-100 and x1p-42-100 SKUs. Put the common part into one dtsi file to be included for model-specific dts. Include the common part in the existing Vivobook S15 device tree. Tested-by: Colin K. Williams <colin@li-nk.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz> Tested-by: Maud Spierings <maud_spierings@hotmail.com> Link: https://lore.kernel.org/r/20260214-b4-vivobook-v3-3-3c88065bbf77@oldschoolsolutions.biz Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-02-25KVM: arm64: Deduplicate ASID retrieval codeMarc Zyngier3-54/+35
We currently have three versions of the ASID retrieval code, one in the S1 walker, and two in the VNCR handling (although the last two are limited to the EL2&0 translation regime). Make this code common, and take this opportunity to also simplify the code a bit while switching over to the TTBRx_EL1_ASID macro. Reviewed-by: Joey Gouly <joey.gouly@arm.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/20260225104718.14209-1-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-02-25x86/efi: defer freeing of boot services memoryMike Rapoport (Microsoft)3-5/+54
efi_free_boot_services() frees memory occupied by EFI_BOOT_SERVICES_CODE and EFI_BOOT_SERVICES_DATA using memblock_free_late(). There are two issue with that: memblock_free_late() should be used for memory allocated with memblock_alloc() while the memory reserved with memblock_reserve() should be freed with free_reserved_area(). More acutely, with CONFIG_DEFERRED_STRUCT_PAGE_INIT=y efi_free_boot_services() is called before deferred initialization of the memory map is complete. Benjamin Herrenschmidt reports that this causes a leak of ~140MB of RAM on EC2 t3a.nano instances which only have 512MB or RAM. If the freed memory resides in the areas that memory map for them is still uninitialized, they won't be actually freed because memblock_free_late() calls memblock_free_pages() and the latter skips uninitialized pages. Using free_reserved_area() at this point is also problematic because __free_page() accesses the buddy of the freed page and that again might end up in uninitialized part of the memory map. Delaying the entire efi_free_boot_services() could be problematic because in addition to freeing boot services memory it updates efi.memmap without any synchronization and that's undesirable late in boot when there is concurrency. More robust approach is to only defer freeing of the EFI boot services memory. Split efi_free_boot_services() in two. First efi_unmap_boot_services() collects ranges that should be freed into an array then efi_free_boot_services() later frees them after deferred init is complete. Link: https://lore.kernel.org/all/ec2aaef14783869b3be6e3c253b2dcbf67dbc12a.camel@kernel.crashing.org Fixes: 916f676f8dc0 ("x86, efi: Retain boot service code until after switching to virtual mode") Cc: <stable@vger.kernel.org> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Reviewed-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2026-02-25arm64: dts: qcom: merge duplicate references to pmc8380_3_gpiosYijie Yang1-2/+0
Merge the two identical references to the pmc8380_3_gpios node to improve clarity and remove redundancy. Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260114-hamoa-v1-1-c96ab354924c@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-02-25arm64: dts: qcom: add apq8096sg-db820c, AP8096SG variant of DB820cDmitry Baryshkov4-1125/+1150
There has been a (rare) variant of Dragonboard 820c, utilizing Pro version of the SoC, with the major difference being CPU and GPU clock tables. Add a DT file representing this version of the board. 01:13:26.275: B - 417880 - 8996 Pro v1.x detected, Max frequency = 1.8 GHz Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251111-db820c-pro-v1-2-6eece16c5c23@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-02-25arm64: dts: imx93-tqma9352: improve eMMC pad configurationMarkus Niebel1-13/+13
Use DSE x4 an PullUp for CMD an DAT, DSE x4 and PullDown for CLK to improve stability and detection at low temperatures under -25°C. Fixes: 0b5fdfaa8e45 ("arm64: dts: freescale: imx93-tqma9352: set SION for cmd and data pad of USDHC") Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-02-25arm64: dts: imx91-tqma9131: improve eMMC pad configurationMarkus Niebel1-10/+10
Use DSE x4 an PullUp for CMD an DAT, DSE x4 and PullDown for CLK to improve stability and detection at low temperatures under -25°C. Fixes: e71db39f0c7c ("arm64: dts: freescale: add initial device tree for TQMa91xx/MBa91xxCA") Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-02-25arm64: dts: imx93-11x11-evk: change usdhc tuning step for eMMC and SDLuke Wang1-0/+2
During system resume, the following errors occurred: [ 430.638625] mmc1: error -84 writing Cache Enable bit [ 430.643618] mmc1: error -84 doing runtime resume For eMMC and SD, there are two tuning pass windows and the gap between those two windows may only have one cell. If tuning step > 1, the gap may just be skipped and host assumes those two windows as a continuous windows. This will cause a wrong delay cell near the gap to be selected. Set the tuning step to 1 to avoid selecting the wrong delay cell. For SDIO, the gap is sufficiently large, so the default tuning step does not cause this issue. Fixes: e37907bd8294 ("arm64: dts: freescale: add i.MX93 11x11 EVK basic support") Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-02-25arm64: dts: imx91-11x11-evk: change usdhc tuning step for eMMC and SDLuke Wang1-0/+2
During system resume, the following errors occurred: [ 430.638625] mmc1: error -84 writing Cache Enable bit [ 430.643618] mmc1: error -84 doing runtime resume For eMMC and SD, there are two tuning pass windows and the gap between those two windows may only have one cell. If tuning step > 1, the gap may just be skipped and host assumes those two windows as a continuous windows. This will cause a wrong delay cell near the gap to be selected. Set the tuning step to 1 to avoid selecting the wrong delay cell. For SDIO, the gap is sufficiently large, so the default tuning step does not cause this issue. Fixes: 6772c4cffd87 ("arm64: dts: freescale: add i.MX91 11x11 EVK basic support") Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-02-24arm64: dts: imx95-evk: update the dma-channel-mask propertyJoy Zou1-2/+5
Have reserved eDMA2 channels 0 and 1 for V2X fast hash in imx95.dtsi. So update the dma-channel-mask from 0xc0000000 to 0xc0000003 to mark channels 0, 1, 30, and 31 as reserved. Signed-off-by: Joy Zou <joy.zou@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-02-24arm64: dts: imx95: Reserve eDMA channels 0-1 for V2XJoy Zou1-0/+2
Reserve eDMA channels 0 and 1 on the AXI eDMA controller for exclusive use by V2X (Vehicle-to-Everything) fast hash operations. Reviewed-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com> Tested-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com> Signed-off-by: Joy Zou <joy.zou@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-02-24arm64: dts: imx93: Add i.MX93 Wireless EVK board supportSherry Sun2-0/+29
i.MX93 Wireless SiP is created by integrating i.MX93 and IW610 WLCSP (Wi-Fi + BLE + 802.15.4). And i.MX93 Wireless EVK board with the i.MX93 Wireless SiP basically reuse the i.MX93 11x11 EVK board, with some minor functional and pin connection differences. Reuse the new imx93-11x11-evk-common.dtsi and add the board-specific changes here. Here are the detailed differences between i.MX93 Wireless EVK and i.MX93 11x11 EVK board. Function differences: Function i.MX93W EVK i.MX93 EVK WIFI/BT IW610 in i.MX93W IW612 M.2 module MQS N Y PDM MIC N Y M.2 N Y RPi 40-pin HDR Limited support(pin conflict) Y Pin connection differences: Function Signal name i.MX93W EVK i.MX93 EVK WIFI/BT SPI_FRM SAI1_TXFS (spi1.PCS0) GPIO_IO08 (spi3.PCS0) SPI_TXD SAI1_TXC (spi1.SIN) GPIO_IO09 (spi3.SIN) SPI_RXD SAI1_RXD0 (spi1.SOUT) GPIO_IO10 (spi3.SOUT) SPI_CLK SAI1_TXD0 (spi1.SCK) GPIO_IO11 (spi3.SCK) SPI_INT CCM_CLKO1 on-board IO expander NB_WAKE_IN PDM_CLK on-module IO expander WL_WAKE_IN PDM_BIT_STREAM0 on-module IO expander IND_RST_WL PDM_BIT_STREAM1 on-module IO expander IND_RST_NB GPIO_IO28 on-module IO expander PDn GPIO_IO29 on-module IO expander NB_WAKE_OUT GPIO_IO14 on-board IO expander WL_WAKE_OUT GPIO_IO15 CCM_CLKO1 I2C3 I2C3_SDA GPIO_IO00 GPIO_IO28 I2C3_SCL GPIO_IO01 GPIO_IO29 Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-02-24arm64: dts: imx93: Add imx93w.dtsi for i.MX93 Wireless SiPSherry Sun1-0/+110
Introduce imx93w.dtsi to describe the new NXP i.MX93 Wireless SiP, which integrates the i.MX93 application processor with the NXP IW610 WLCSP (Wi-Fi + Bluetooth LE + 802.15.4) connectivity device. The new imx93w.dtsi is based on imx93.dtsi and adds the pieces required for the internal connection between i.MX93 and IW610 inside the SiP. This includes USDHC3 which is used as the host interface to the IW610 and the required GPIO settings(e.g. WL_RST, WL_REG_ON, etc.). These nodes reflect internal SiP wiring and are not board specific, so they are placed in a dedicated imx93w.dtsi file that can be reused by multiple boards adopting the i.MX93 Wireless SiP. Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-02-24arm64: dts: imx93: Move 11x11 EVK specific parts back to imx93-11x11-evk.dtsSherry Sun2-198/+206
The previous patch renamed imx93-11x11-evk.dts to imx93-11x11-evk-common.dtsi to prepare for adding the i.MX93 Wireless EVK, which shares most of its design with the 11x11 EVK. Move the board specific differences out of imx93-11x11-evk-common.dtsi and back into imx93-11x11-evk.dts, ensuring that the common dtsi only contains the truly shared parts between the two EVK boards. No functional changes intended. Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-02-24arm64: dts: imx93: Extract common EVK description into shared dtsiSherry Sun2-1051/+1059
The i.MX93 Wireless EVK reuses most of the 11x11 EVK design. To avoid duplication and DTS-to-DTS includes, extract the common parts into a new imx93-11x11-evk-common.dtsi shared by both boards. Rename imx93-11x11-evk.dts to imx93-11x11-evk-common.dtsi and include it from imx93-11x11-evk.dts. Only structural changes are introduced, with no intended functional impact. Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-02-24arm64: dts: imx93-9x9-qsb: change usdhc tuning step for eMMC and SDLuke Wang1-0/+2
During system resume, the following errors occurred: [ 430.638625] mmc1: error -84 writing Cache Enable bit [ 430.643618] mmc1: error -84 doing runtime resume For eMMC and SD, there are two tuning pass windows and the gap between those two windows may only have one cell. If tuning step > 1, the gap may just be skipped and host assumes those two windows as a continuous windows. This will cause a wrong delay cell near the gap to be selected. Set the tuning step to 1 to avoid selecting the wrong delay cell. For SDIO, the gap is sufficiently large, so the default tuning step does not cause this issue. Fixes: 0565d20cd8c2 ("arm64: dts: freescale: Support i.MX93 9x9 Quick Start Board") Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-02-24arm64: dts: imx95-15x15-frdm: support AONMIX MQSLaurentiu Mihalcea1-0/+73
Add support for AONMIX MQS (i.e. MQS1). Reviewed-by: Chancel Liu <chancel.liu@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-02-24arm64: dts: imx95: add AONMIX MQS nodeLaurentiu Mihalcea1-0/+5
Add DT node for AONMIX MQS (i.e. MQS1). Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-02-24arm64: dts: freescale: imx95-toradex-smarc: fix PMIC_SD2_VSEL label positionEmanuele Ghidoli1-1/+0
Fix the PMIC_SD2_VSEL gpio-line-name position. It should be on line 19 of gpio3, not line 20. Fixes: 90bbe88e0ea6 ("arm64: dts: freescale: add Toradex SMARC iMX95") Cc: stable@vger.kernel.org Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-02-24ARM: dts: imx51-babbage: rename at45db321d@1 to flash@1Frank Li1-1/+1
Rename at45db321d@1 to flash@1 to fix below CHECK_DTBS warnings: at45db321d@1 (atmel,at45db321d): $nodename:0: 'at45db321d@1' does not match '^(flash|.*sram|nand)(@.*)?$' from schema $id: http://devicetree.org/schemas/mtd/atmel,dataflash.yaml Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-02-24ARM: dts: imx51-ts4800: rename fpga@0 to fpga@0,0Frank Li1-1/+1
Change node name fpga@0 to fpga@0,0 to fix below CHECK_DTBS warnings: memory-controller@83fda000 (fsl,imx51-weim): 'fpga@0' does not match any of the regexes: '^.*@[0-7],[0-9a-f]+$', '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/memory-controllers/fsl/fsl,imx-weim.yam Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-02-24ARM: dts: imx35: remove simple-bus 'usbphy'Frank Li1-15/+7
Remove simple bus 'usbphy' and move chip nodes to up layers to fix below CHECK_DTBS warnings. arch/arm/boot/dts/nxp/imx/imx35-pdk.dtb: usbphy (simple-bus): usb-phy@1:reg:0: [1] is too short from schema $id: http://devicetree.org/schemas/simple-bus.yaml Remove property 'reg' because it is never used at driver. Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-02-24ARM: dts: imx35: rename i2c clock-names to ipgFrank Li1-3/+3
Rename the i2c clock-names from "ipg_per" to "ipg" to match the binding documentation. Fix the following CHECK_DTBS warning: i2c@43f80000 (fsl,imx35-i2c): clock-names:0: 'ipg' was expected Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-02-24ARM: dts: imx35: rename emi to emi-bus to fix CHECK_DTBS warningFrank Li2-2/+2
Rename emi to emi-bus to fix below CHECK_DTBS warning: arch/arm/boot/dts/nxp/imx/imx31-bug.dtb: emi@b8000000 (simple-bus): $nodename:0: 'emi@b8000000' does not match '^([a-z][a-z0-9\\-]+-bus|bus|localbus|soc|axi|ahb|apb)(@.+)?$' from schema $id: http://devicetree.org/schemas/simple-bus.yaml Signed-off-by: Frank Li <Frank.Li@nxp.com>