summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2026-03-23ARM: dts: rockchip: Fix the trackpad supply on rk3288-veyron-jerryFabio Estevam1-1/+1
According to hid-over-i2c.yaml, the correct name for the 3.3V supply is 'vdd-supply'. Fix it accordingly. This fixes the following dt-schema warning: 'vcc-supply' does not match any of the regexes: '^pinctrl-[0-9]+$' Signed-off-by: Fabio Estevam <festevam@gmail.com> Reviewed-by: Charalampos Mitrodimas <charmitro@posteo.net> Link: https://patch.msgid.link/20260304164448.1024410-1-festevam@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-03-23ARM: dts: rockchip: Fix the Bluetooth node name on rk3288-veyronFabio Estevam2-2/+2
Node names should be generic, so use 'bluetooth' as the node name. This fixes the following dt-schema warning: 'btmrvl@2' does not match '^bluetooth(@.*)?$' Signed-off-by: Fabio Estevam <festevam@gmail.com> Link: https://patch.msgid.link/20260226144842.2727107-2-festevam@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-03-23ARM: dts: rockchip: Remove invalid regulator-property from rk3288-veyronFabio Estevam2-4/+0
The 'regulator-suspend-mem-disabled' property is not documented nor used anywhere. Remove this invalid property. This fixes the following dt-schema warning: ('regulator-suspend-mem-disabled' was unexpected) Signed-off-by: Fabio Estevam <festevam@gmail.com> Link: https://patch.msgid.link/20260226144842.2727107-1-festevam@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-03-23ARM: dts: rockchip: Use mount-matrix on rk3188-bqedison2qcFabio Estevam1-1/+1
'rotation-matrix' is not a valid property. Use the documented 'mount-matrix' property instead. This fixes the following dt-schema warning: accelerometer@29 (st,lis3de): 'rotation-matrix' does not match any of the regexes: '^pinctrl-[0-9]+$' accelerometer@29 (st,lis3de): rotation-matrix: b'1\x000\x000\x000\x00-1\x000\x000\x000\x001\x00' is not of type 'object', 'integer', 'array', 'boolean', 'null' Signed-off-by: Fabio Estevam <festevam@gmail.com> Link: https://patch.msgid.link/20260226145916.2729492-1-festevam@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-03-23ARM: dts: rockchip: Fix RTC compatible on rk3288-phycore-rdkFabio Estevam1-1/+1
According to st,m41t80.yaml, the correct compatible for the RV4162 RTC is "microcrystal,rv4162". Fix it accordingly. This fixes the following dt-schema warning: rtc@68: failed to match any schema with compatible: ['rv4162'] Signed-off-by: Fabio Estevam <festevam@gmail.com> Link: https://patch.msgid.link/20260301124156.473862-1-festevam@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-03-23ARM: dts: rockchip: Move PHY reset to ethernet-phy node on rk3036 boardsFabio Estevam2-4/+4
According to rockchip,emac.yaml, 'phy-reset-duration' and 'phy-reset-gpios' are not valid properties. Use the valid 'reset-gpios' and 'reset-assert-us' properties under the etherne-phy node. This fixes the following dt-schema warning: Unevaluated properties are not allowed ('phy-reset-duration', 'phy-reset-gpios' were unexpected) Signed-off-by: Fabio Estevam <festevam@gmail.com> Link: https://patch.msgid.link/20260228013257.256973-1-festevam@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-03-23ARM: dts: rockchip: Remove rockchip,grf from rk3288 tsadcFabio Estevam1-1/+0
According to rockchip-thermal.yaml, RK3288 does not require rockchip,grf, so remove this invalid property. This fixes the following dt-schema warning: tsadc@ff280000 (rockchip,rk3288-tsadc): False schema does not allow [[53]] The rockchip_thermal driver also confirms that grf is not needed as the rk3288_tsadc_data contains: .grf_required = false, Signed-off-by: Fabio Estevam <festevam@gmail.com> Link: https://patch.msgid.link/20260228013257.256973-2-festevam@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-03-23lib: count_zeros: unify count_{leading,trailing}_zeros()Yury Norov1-2/+2
The 'leading' helper returns BITS_PER_LONG if x == 0, while 'trailing' one returns COUNT_TRAILING_ZEROS_0, which turns to be -1. None of the current users explicitly check the returned value for COUNT_TRAILING_ZEROS_0, except the loongarch, which tests implicitly for the '>= 0'. So, align count_trailing_zeros() with the count_leading_zeros(), and simplify the loongarch handling. Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Yury Norov <ynorov@nvidia.com>
2026-03-23x86/topology: use bitmap_weight_from()Yury Norov1-6/+2
Switch topo_unit_count() to use bitmap_weight_from(). Signed-off-by: Yury Norov <ynorov@nvidia.com>
2026-03-23arm64: defconfig: Enable Lontium LT8713sx driverVishnu Saini1-0/+1
Lontium LT8713sx DP bridge hub can be found on a Qualcomm Monaco EVK board for converting 1 DP to 3 DP outputs. Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260319-lt8713sx-bridge-linux-for-next-v4-2-da886ec78fe3@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-23arm64: defconfig: Enable Qualcomm Eliza SoC display clock controllerKrzysztof Kozlowski1-0/+1
Enable the driver for Qualcomm Eliza SoC display clock controller, used for example on Qualcomm Eliza MTP board. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260319-clk-qcom-dispcc-eliza-v3-3-d1f2b19a6e6b@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-23arm64: defconfig: enable IPQ5210 RDP504 base configsKathiravan Thirumoorthy1-0/+2
Enable GCC, Pinctrl for Qualcomm's IPQ5210 SoC which is required to boot ipq5210-rdp504 board to a console shell. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260318-ipq5210_boot_to_shell-v2-6-a87e27c37070@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-23arm64: defconfig: Enable Milos LPASS LPI pinctrl driverLuca Weiss1-0/+1
Build the LPASS LPI pinctrl driver as module, as required by devices using the Qualcomm Milos SoC. Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Link: https://lore.kernel.org/r/20260306-milos-pinctrl-lpi-v1-3-086946dbb855@fairphone.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-23arm64: defconfig: Enable Kaanapali clock controllersTaniya Das1-0/+4
Enable the Kaanapali display, video, camera and gpu clock controller for their respective functionalities on the Qualcomm Kaanapali QRD and MTP boards. Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260224-knp-dts-misc-v6-10-79d20dab8a60@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-23x86/cpu/topology: Consolidate AMD and Hygon cases in parse_topology()Wei Wang1-6/+2
Merge the two separate switch cases for AMD and Hygon as they share the common cpu_parse_topology_amd(). Also drop the IS_ENABLED(CONFIG_CPU_SUP_AMD/HYGON) guards, because 1) they are dead code: when a vendor's CONFIG_CPU_SUP_* is disabled, its vendor detection code (in amd.c / hygon.c) is not compiled, so x86_vendor will never be set to X86_VENDOR_AMD / X86_VENDOR_HYGON, instead it will default to X86_VENDOR_UNKNOWN and those switch cases are unreachable. 2) topology_amd.o is always built (obj-y), so cpu_parse_topology_amd() is always available regardless of CPU_SUP_* configuration. Signed-off-by: Wei Wang <wei.w.wang@hotmail.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Tested-by: Yongwei Xu <xuyongwei@open-hieco.net> Link: https://patch.msgid.link/SI2PR01MB4393D6B7E17AB05612AEE925DC4BA@SI2PR01MB4393.apcprd01.prod.exchangelabs.com
2026-03-23arm64: dts: marvell: armada-37xx: drop 'marvell,usb-misc-reg' from USB host ↵Gabor Juhos1-2/+0
nodes The 'marvell,usb-misc-reg' property is present both in the EHCI and in the XHCI USB host device nodes, however it is not documented. Thus 'make dtbs_check' produces warnings like these: /arch/arm64/boot/dts/marvell/armada-3720-db.dtb: usb@58000 (marvell,armada3700-xhci): Unevaluated properties are not allowed ('marvell,usb-misc-reg' was unexpected) from schema $id: http://devicetree.org/schemas/usb/generic-xhci.yaml /arch/arm64/boot/dts/marvell/armada-3720-db.dtb: usb@5e000 (marvell,armada-3700-ehci): Unevaluated properties are not allowed ('marvell,usb-misc-reg' was unexpected) from schema $id: http://devicetree.org/schemas/usb/generic-ehci.yaml Apart from the fact that the properties are not documented, those are not even used by any USB host drivers. Due to this, drop the properties in order to get rid of the warnings. Note: With the same name, there is a property used for the Armada 3700 USB UTMI PHYs of which dt-bindings documentation has been added in commit e60958699afa ("dt-bindings: phy: mvebu-utmi: add UTMI PHY bindings"). Additionally, the property is handled by the 'phy-mvebu-a3700-utmi' driver since commit cc8b7a0ae866 ("phy: add A3700 UTMI PHY driver"). When the nodes of the UTMI PHYs has been added to the SoC dtsi by commit 05d168a56fae ("arm64: dts: marvell: armada-37xx: declare USB2 UTMI PHYs"), the properties has been added to the USB host controller nodes also. According to the commit message this was unintentional, however in regard to the USB hosts, neither the respective documentation, nor driver support has been added into the tree since that. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2026-03-23x86/cpu: Add comment clarifying CRn pinningPeter Zijlstra1-0/+13
To avoid future confusion on the purpose and design of the CRn pinning code. Also note that if the attacker controls page-tables, the CRn bits lose much of the attraction anyway. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20260320092521.GG3739106@noisy.programming.kicks-ass.net
2026-03-23x86/fred: Fix early boot failures on SEV-ES/SNP guestsNikunj A Dadhania2-0/+20
FRED-enabled SEV-(ES,SNP) guests fail to boot due to the following issues in the early boot sequence: * FRED does not have a #VC exception handler in the dispatch logic * Early FRED #VC exceptions attempt to use uninitialized per-CPU GHCBs instead of boot_ghcb Add X86_TRAP_VC case to fred_hwexc() with a new exc_vmm_communication() function that provides the unified entry point FRED requires, dispatching to existing user/kernel handlers based on privilege level. The function is already declared via DECLARE_IDTENTRY_VC(). Fix early GHCB access by falling back to boot_ghcb in __sev_{get,put}_ghcb() when per-CPU GHCBs are not yet initialized. Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code") Signed-off-by: Nikunj A Dadhania <nikunj@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Cc: <stable@kernel.org> # 6.12+ Link: https://patch.msgid.link/20260318075654.1792916-4-nikunj@amd.com
2026-03-23x86/cpu: Remove X86_CR4_FRED from the CR4 pinned bits maskBorislav Petkov (AMD)1-1/+1
Commit in Fixes added the FRED CR4 bit to the CR4 pinned bits mask so that whenever something else modifies CR4, that bit remains set. Which in itself is a perfectly fine idea. However, there's an issue when during boot FRED is initialized: first on the BSP and later on the APs. Thus, there's a window in time when exceptions cannot be handled. This becomes particularly nasty when running as SEV-{ES,SNP} or TDX guests which, when they manage to trigger exceptions during that short window described above, triple fault due to FRED MSRs not being set up yet. See Link tag below for a much more detailed explanation of the situation. So, as a result, the commit in that Link URL tried to address this shortcoming by temporarily disabling CR4 pinning when an AP is not online yet. However, that is a problem in itself because in this case, an attack on the kernel needs to only modify the online bit - a single bit in RW memory - and then disable CR4 pinning and then disable SM*P, leading to more and worse things to happen to the system. So, instead, remove the FRED bit from the CR4 pinning mask, thus obviating the need to temporarily disable CR4 pinning. If someone manages to disable FRED when poking at CR4, then idt_invalidate() would make sure the system would crash'n'burn on the first exception triggered, which is a much better outcome security-wise. Fixes: ff45746fbf00 ("x86/cpu: Add X86_CR4_FRED macro") Suggested-by: Dave Hansen <dave.hansen@linux.intel.com> Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: <stable@kernel.org> # 6.12+ Link: https://lore.kernel.org/r/177385987098.1647592.3381141860481415647.tip-bot2@tip-bot2
2026-03-23x86/cpu: Enable FSGSBASE early in cpu_init_exception_handling()Nikunj A Dadhania1-6/+12
Move FSGSBASE enablement from identify_cpu() to cpu_init_exception_handling() to ensure it is enabled before any exceptions can occur on both boot and secondary CPUs. == Background == Exception entry code (paranoid_entry()) uses ALTERNATIVE patching based on X86_FEATURE_FSGSBASE to decide whether to use RDGSBASE/WRGSBASE instructions or the slower RDMSR/SWAPGS sequence for saving/restoring GSBASE. On boot CPU, ALTERNATIVE patching happens after enabling FSGSBASE in CR4. When the feature is available, the code is permanently patched to use RDGSBASE/WRGSBASE, which require CR4.FSGSBASE=1 to execute without triggering == Boot Sequence == Boot CPU (with CR pinning enabled): trap_init() cpu_init() <- Uses unpatched code (RDMSR/SWAPGS) x2apic_setup() ... arch_cpu_finalize_init() identify_boot_cpu() identify_cpu() cr4_set_bits(X86_CR4_FSGSBASE) # Enables the feature # This becomes part of cr4_pinned_bits ... alternative_instructions() <- Patches code to use RDGSBASE/WRGSBASE Secondary CPUs (with CR pinning enabled): start_secondary() cr4_init() <- Code already patched, CR4.FSGSBASE=1 set implicitly via cr4_pinned_bits cpu_init() <- exceptions work because FSGSBASE is already enabled Secondary CPU (with CR pinning disabled): start_secondary() cr4_init() <- Code already patched, CR4.FSGSBASE=0 cpu_init() x2apic_setup() rdmsrq(MSR_IA32_APICBASE) <- Triggers #VC in SNP guests exc_vmm_communication() paranoid_entry() <- Uses RDGSBASE with CR4.FSGSBASE=0 (patched code) ... ap_starting() identify_secondary_cpu() identify_cpu() cr4_set_bits(X86_CR4_FSGSBASE) <- Enables the feature, which is too late == CR Pinning == Currently, for secondary CPUs, CR4.FSGSBASE is set implicitly through CR-pinning: the boot CPU sets it during identify_cpu(), it becomes part of cr4_pinned_bits, and cr4_init() applies those pinned bits to secondary CPUs. This works but creates an undocumented dependency between cr4_init() and the pinning mechanism. == Problem == Secondary CPUs boot after alternatives have been applied globally. They execute already-patched paranoid_entry() code that uses RDGSBASE/WRGSBASE instructions, which require CR4.FSGSBASE=1. Upcoming changes to CR pinning behavior will break the implicit dependency, causing secondary CPUs to generate #UD. This issue manifests itself on AMD SEV-SNP guests, where the rdmsrq() in x2apic_setup() triggers a #VC exception early during cpu_init(). The #VC handler (exc_vmm_communication()) executes the patched paranoid_entry() path. Without CR4.FSGSBASE enabled, RDGSBASE instructions trigger #UD. == Fix == Enable FSGSBASE explicitly in cpu_init_exception_handling() before loading exception handlers. This makes the dependency explicit and ensures both boot and secondary CPUs have FSGSBASE enabled before paranoid_entry() executes. Fixes: c82965f9e530 ("x86/entry/64: Handle FSGSBASE enabled paranoid entry/exit") Reported-by: Borislav Petkov <bp@alien8.de> Suggested-by: Sohil Mehta <sohil.mehta@intel.com> Signed-off-by: Nikunj A Dadhania <nikunj@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Sohil Mehta <sohil.mehta@intel.com> Cc: <stable@kernel.org> Link: https://patch.msgid.link/20260318075654.1792916-2-nikunj@amd.com
2026-03-23fs: fix archiecture-specific compat_ftruncate64Christoph Hellwig6-7/+8
The "small" argument to do_sys_ftruncate indicates if > 32-bit size should be reject, but all the arch-specific compat ftruncate64 implementations get this wrong. Merge do_sys_ftruncate and ksys_ftruncate, replace the integer as boolean small flag with a descriptive one about LFS semantics, and use it correctly in the architecture-specific ftruncate64 implementations. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Fixes: 3dd681d944f6 ("arm64: 32-bit (compat) applications support") Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260323070205.2939118-2-hch@lst.de Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-03-23KVM: arm64: Remove extra ISBs when using msr_hcr_el2Marc Zyngier4-8/+2
The msr_hcr_el2 macro is slightly awkward, as it provides an ISB when CONFIG_AMPERE_ERRATUM_AC04_CPU_23 is present, and none otherwise. Note that this this option is 'default y', meaning that it is likely to be selected. Most instances of msr_hcr_el2 are also immediately followed by an ISB, meaning that in most cases, you end-up with two back-to-back ISBs. This isn't a big deal, but once you have seen that, you can't unsee it. Rework the msr_hcr_el2 macro to always provide the ISB, and drop the superfluous ISBs everywhere else. Reviewed-by: Fuad Tabba <tabba@google.com> Tested-by: Fuad Tabba <tabba@google.com> Link: https://patch.msgid.link/20260321212419.2803972-6-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-23KVM: arm64: pkvm: Use direct function pointers for cpu_{on,resume}Marc Zyngier3-22/+29
Instead of using a boolean to decide whether a CPU is booting or resuming, just pass an actual function pointer around. This makes the code a bit more straightforward to understand. Reviewed-by: Fuad Tabba <tabba@google.com> Tested-by: Fuad Tabba <tabba@google.com> Link: https://patch.msgid.link/20260321212419.2803972-5-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-23KVM: arm64: pkvm: Turn __kvm_hyp_init_cpu into an inner labelMarc Zyngier1-12/+3
__kvm_hyp_init_cpu really is an internal label for kvm_hyp_cpu_entry and kvm_hyp_cpu_resume. Make it clear that this is what it is, and drop a pointless branch in kvm_hyp_cpu_resume. Reviewed-by: Fuad Tabba <tabba@google.com> Tested-by: Fuad Tabba <tabba@google.com> Link: https://patch.msgid.link/20260321212419.2803972-4-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-23KVM: arm64: pkvm: Simplify BTI handling on CPU bootMarc Zyngier2-14/+5
In order to perform an indirect branch to kvm_host_psci_cpu_entry() on a BTI-aware system, we first branch to a 'BTI j' landing pad, and from there branch again to the target. While this works, this is really not required: - BLR works with 'BTI c' and 'PACIASP' as the landing pad - Even if LR gets clobbered by BLR, we are going to restore the host's registers, so it is pointless to try and avoid touching LR Given the above, drop the veneer and directly call into C code. If we were to come back from it, we'd directly enter the error handler. Reviewed-by: Fuad Tabba <tabba@google.com> Tested-by: Fuad Tabba <tabba@google.com> Link: https://patch.msgid.link/20260321212419.2803972-3-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-23KVM: arm64: pkvm: Move error handling to the end of kvm_hyp_cpu_entryMarc Zyngier1-7/+7
We currently handle CPUs having booted at EL1 in the middle of the kvm_hyp_cpu_entry function. Not only this adversely affects readability, but this is also at a bizarre spot should more error handling be added (which we're about to do). Move the WFE/WFI loop to the end of the function and fix a comment. Reviewed-by: Fuad Tabba <tabba@google.com> Tested-by: Fuad Tabba <tabba@google.com> Link: https://patch.msgid.link/20260321212419.2803972-2-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-23ARM: dts: microchip: sam9x7: fix gpio-lines count for pioBMihai Sain1-1/+1
The pioB controller on the SAM9X7 SoC actually supports 27 GPIO lines. The previous value of 26 was incorrect, leading to the last pin being unavailable for use by the GPIO subsystem. Update the #gpio-lines property to reflect the correct hardware specification. Fixes: 41af45af8bc3 ("ARM: dts: at91: sam9x7: add device tree for SoC") Signed-off-by: Mihai Sain <mihai.sain@microchip.com> Link: https://lore.kernel.org/r/20260209090735.2016-1-mihai.sain@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
2026-03-23arm64: dts: ti: k3-j722s: Add main_i2c4 device nodeAniket Limaye3-7/+22
Add missing device tree node for main_i2c4, and the corresponding ranges in cbass_main. Interrupt for this i2c controller is routed through the Main GPIOMUX Router. Base address, Interrupt IDs are taken from J722S TRM [0]. Device, Clock IDs are taken from TISCI docs [1]. Additionally, the I2C4 is the only interrupt source to the GPIOMUX INTR router that generates level interrupts, while all other sources generate edge interrupts. Due to this, the router needs to handle interrupt-type on a per-line basis. Modify the router node and its consumers to specify the interrupt type corresponding to each interrupt line. [0]: https://www.ti.com/lit/zip/sprujb3 [1]: https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/index.html#j722s Signed-off-by: Jared McArthur <j-mcarthur@ti.com> Signed-off-by: Aniket Limaye <a-limaye@ti.com> Tested-by: Nora Schiffer <nora.schiffer@ew.tq-group.com> Link: https://patch.msgid.link/20260304-j722s-main-i2c4-dt-v1-1-03f79f0cdf97@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2026-03-23KVM: arm64: nv: Expose shadow page tables in debugfsWei-Lin Chang4-1/+44
Exposing shadow page tables in debugfs improves the debugability and testability of NV. With this patch a new directory "nested" is created for each VM created if the host is NV capable. Within the directory each valid s2 mmu will have its shadow page table exposed as a readable file with the file name formatted as 0x<vttbr>-0x<vtcr>-s2-{en,dis}abled. The creation and removal of the files happen at the points when an s2 mmu becomes valid, or the context it represents change. In the future the "nested" directory can also hold other NV related information. This is gated behind CONFIG_PTDUMP_STAGE2_DEBUGFS. Suggested-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Sebastian Ene <sebastianene@google.com> Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com> Reviewed-by: Joey Gouly <joey.gouly@arm.com> Link: https://patch.msgid.link/20260317182638.1592507-3-weilin.chang@arm.com [maz: minor refactor, full 16 chars addresses] Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-23arm64: dts: arm/corstone1000: Add corstone-1000-a320Rob Herring (Arm)3-0/+107
The Corstone-1000-a320 is a Corstone-1000 derivative with Cortex-A320 cores, GIC-600, and Ethos-U85 NPU. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Message-Id: <20260320-dt-corstone1000-a320-v1-5-a549dfcfe8da@kernel.org> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-03-23arm64: dts: arm/corstone1000: Move FVP peripherals to separate .dtsiRob Herring (Arm)2-35/+45
The FVPs have a common set of peripherals specific to the FVP. Move these to a separate .dtsi so they can be shared across FVP platforms. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Message-Id: <20260320-dt-corstone1000-a320-v1-4-a549dfcfe8da@kernel.org> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-03-23arm64: dts: arm/corstone1000: Move cpu nodesRob Herring (Arm)3-35/+45
In preparation to add a new Corstone-1000 variation with different CPUs, move the CPU nodes into the specific platforms and out of the common corstone1000.dtsi. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Message-Id: <20260320-dt-corstone1000-a320-v1-3-a549dfcfe8da@kernel.org> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-03-23arm64: dts: renesas: r9a09g047e57-smarc: Enable RSPI0Tommaso Merciai1-0/+16
Enable RSPI0 on the RZ/G3E SMARC EVK, where it is accessible on the PMOD0 connector. Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/b634c10e632fed07b5652c11de060deca27ead90.1771344527.git.tommaso.merciai.xr@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-23arm64: dts: renesas: r9a09g047: Add RSPI nodesTommaso Merciai1-0/+84
Add nodes for the RSPI IPs found in the Renesas RZ/G3E SoC. Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/c8df5202caf4e36ee5beafe78ad0940643edcbb6.1771344527.git.tommaso.merciai.xr@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-22Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf 7.0-rc5Alexei Starovoitov115-1074/+1025
Cross-merge BPF and other fixes after downstream PR. Minor conflicts in: tools/testing/selftests/bpf/progs/exceptions_fail.c tools/testing/selftests/bpf/progs/verifier_bounds.c Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-03-22Merge tag 'x86-urgent-2026-03-22' of ↵Linus Torvalds3-9/+28
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Ingo Molnar: - Improve Qemu MCE-injection behavior by only using AMD SMCA MSRs if the feature bit is set - Fix the relative path of gettimeofday.c inclusion in vclock_gettime.c - Fix a boot crash on UV clusters when a socket is marked as 'deconfigured' which are mapped to the SOCK_EMPTY node ID by the UV firmware, while Linux APIs expect NUMA_NO_NODE. The difference being (0xffff [unsigned short ~0]) vs [int -1] * tag 'x86-urgent-2026-03-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/platform/uv: Handle deconfigured sockets x86/entry/vdso: Fix path of included gettimeofday.c x86/mce/amd: Check SMCA feature bit before accessing SMCA MSRs
2026-03-22Merge tag 'perf-urgent-2026-03-22' of ↵Linus Torvalds3-16/+33
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf fixes from Ingo Molnar: - Fix a PMU driver crash on AMD EPYC systems, caused by a race condition in x86_pmu_enable() - Fix a possible counter-initialization bug in x86_pmu_enable() - Fix a counter inheritance bug in inherit_event() and __perf_event_read() - Fix an Intel PMU driver branch constraints handling bug found by UBSAN - Fix the Intel PMU driver's new Off-Module Response (OMR) support code for Diamond Rapids / Nova lake, to fix a snoop information parsing bug * tag 'perf-urgent-2026-03-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86/intel: Fix OMR snoop information parsing issues perf/x86/intel: Add missing branch counters constraint apply perf: Make sure to use pmu_ctx->pmu for groups x86/perf: Make sure to program the counter value for stopped events on migration perf/x86: Move event pointer setup earlier in x86_pmu_enable()
2026-03-22arm64: dts: ti: k3-j721s2: Use ti,j7200-padconf compatibleThomas Richard (TI)2-9/+9
On the J721S2 platform, pinctrl contexts must be saved and restored during suspend-to-ram, just like on the J7200. So use ti,j7200-padconf compatible. Signed-off-by: Thomas Richard (TI) <thomas.richard@bootlin.com> Link: https://patch.msgid.link/20260313-j721s2-s2r-pinctrl-v1-1-a6f80c641037@bootlin.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2026-03-22arm64: dts: ti: k3-am68-phyboard-izar: Add PEB-AV-15 overlayDominik Haller2-0/+195
Add an overlay to use the PEB-AV-15 AV-Adapter. It's a small expansion board using a Lontium LT8912B DSI->HDMI bridge and a TLV320AIC3007 audio codec. Signed-off-by: Dominik Haller <d.haller@phytec.de> Link: https://patch.msgid.link/20260320212349.420951-6-d.haller@phytec.de Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2026-03-22arm64: dts: ti: k3-j721s2-main: Add DSI1Dominik Haller1-0/+39
Add the second DSI instance and its corresponding phy to the main domain include file. Signed-off-by: Dominik Haller <d.haller@phytec.de> Reviewed-by: Beleswar Padhi <b-padhi@ti.com> Link: https://patch.msgid.link/20260320212349.420951-5-d.haller@phytec.de Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2026-03-22arm64: dts: ti: k3-am68-phyboard-izar: Add LVDS-DisplayDominik Haller2-0/+129
Add an overlay to use a powertip,ph128800t006-zhc01 10.1" LVDS display. Signed-off-by: Dominik Haller <d.haller@phytec.de> Link: https://patch.msgid.link/20260320212349.420951-4-d.haller@phytec.de Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2026-03-22arm64: dts: ti: k3-am68-phycore-som: Add DSI->LVDS bridgeDominik Haller1-0/+17
Add the TI SN65DSI83 MIPI-DSI->LVDS bridge that can be populated on the phyCORE-AM68x/TDA4x. Signed-off-by: Dominik Haller <d.haller@phytec.de> Link: https://patch.msgid.link/20260320212349.420951-3-d.haller@phytec.de Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2026-03-22arm64: dts: ti: k3-am68-phyboard-izar: Assign dss clocksDominik Haller1-0/+17
Assign the dss clocks in the base dts so that display overlays can be used in any combination. Signed-off-by: Dominik Haller <d.haller@phytec.de> Link: https://patch.msgid.link/20260320212349.420951-2-d.haller@phytec.de Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2026-03-22arm64: dts: ti: am62-verdin: Enable pullup for eMMC data pinsFrancesco Dolcini1-10/+10
Verdin AM62 board does not have external pullups on eMMC DAT1-DAT7 pins. 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, 10kohm-150kohm per JEDEC), which may exceed the recommended 50kohm max for 1.8V VCCQ - JEDEC JESD84-B51 Table 200 requires host-side pullups (R_DAT, 10kohm-100kohm) on all data lines to prevent bus floating Fixes: 316b80246b16 ("arm64: dts: ti: add verdin am62") Cc: stable@vger.kernel.org Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://patch.msgid.link/20260320073032.10427-1-francesco@dolcini.it Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2026-03-22block/floppy: Don't use REALLY_SLOW_IO for delaysJuergen Gross2-10/+22
Instead of defining REALLY_SLOW_IO before including io.h, add the required additional calls of native_io_delay() to the related functions in arch/x86/include/asm/floppy.h. Drop REALLY_SLOW_IO now too as it has no users. [ bp: Merge the REALLY_SLOW_IO removal into this patch. ] Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://patch.msgid.link/20260119182632.596369-4-jgross@suse.com
2026-03-22x86/paravirt: Replace io_delay() hook with a boolJuergen Gross8-31/+16
The io_delay() paravirt hook is in no way performance critical and all users setting it to a different function than native_io_delay() are using an empty function as replacement. Allow replacing the hook with a bool indicating whether native_io_delay() should be called. [ bp: Massage commit message. ] Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://patch.msgid.link/20260119182632.596369-3-jgross@suse.com
2026-03-22x86/irqflags: Preemptively move include paravirt.h directive where it belongsJuergen Gross1-3/+3
Commit 22cc5ca5de52 ("x86/paravirt: Move halt paravirt calls under CONFIG_PARAVIRT") moved some paravirt hooks from the CONFIG_PARAVIRT_XXL umbrella to CONFIG_PARAVIRT, but missed to move the associated "#include <asm/paravirt.h>" in irqflags.h from CONFIG_PARAVIRT_XXL to CONFIG_PARAVIRT. This hasn't resulted in build failures yet, as all use cases of irqflags.h had paravirt.h included via other header files, even without CONFIG_PARAVIRT_XXL being set. In order to allow changing those other header files, e.g. by no longer including paravirt.h, fix irqflags.h by moving inclusion of paravirt.h under the CONFIG_PARAVIRT umbrella. [ bp: Massage commit message. ] Fixes: 22cc5ca5de52 ("x86/paravirt: Move halt paravirt calls under CONFIG_PARAVIRT") Closes: https://lore.kernel.org/oe-kbuild-all/202601152203.plJOoOEF-lkp@intel.com/ Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://patch.msgid.link/20260119182632.596369-2-jgross@suse.com
2026-03-21Merge tag 'driver-core-7.0-rc5' of ↵Linus Torvalds1-4/+0
git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core Pull driver core fixes from Danilo Krummrich: - Generalize driver_override in the driver core, providing a common sysfs implementation and concurrency-safe accessors for bus implementations - Do not use driver_override as IRQ name in the hwmon axi-fan driver - Remove an unnecessary driver_override check in sh platform_early - Migrate the platform bus to use the generic driver_override infrastructure, fixing a UAF condition caused by accessing the driver_override field without proper locking in the platform_match() callback * tag 'driver-core-7.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core: driver core: platform: use generic driver_override infrastructure sh: platform_early: remove pdev->driver_override check hwmon: axi-fan: don't use driver_override as IRQ name docs: driver-model: document driver_override driver core: generalize driver_override in struct device
2026-03-21Merge tag 'v7.1-rockchip-dts64-1' of ↵Krzysztof Kozlowski25-62/+2083
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into soc/dt New boards: RK3576-EVB2, OneThing Edge Cube New soc-peripherals: DisplayPort on RK3576 New overlays: TSx33 device-revisions, HD702E display/touchscreen on NanoPC-T4 And as always a number of per-board changes for added or enabled peripherals, added supplies, things moved to more fitting positions. * tag 'v7.1-rockchip-dts64-1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: (28 commits) arm64: dts: rockchip: enable vicap dvp on wolfvision pf5 io expander arm64: dts: rockchip: Add analog audio switches to RK3576 EVB1 arm64: dts: rockchip: Enable GPU on rk3566-pinenote arm64: dts: rockchip: Make Jaguar PCIe-refclk pin use pull-up config arm64: dts: rockchip: add pinctrl for clk-generator GPIO on rk3588-tiger arm64: dts: rockchip: use gated-fixed-clock for pcie-refclk on rk3588-tiger arm64: dts: rockchip: use gated-fixed-clock for pcie-refclk on rk3588-jaguar arm64: dts: rockchip: Enable displayport for rk3576 evb2 arm64: dts: rockchip: Add battery and charger on rk3566-pinenote arm64: dts: rockchip: Fix sdmmc pwren pinctrl for rk3576-evb2 arm64: dts: rockchip: Describe HDMI supplies for nanopi4 boards arm64: dts: rockchip: Clean up NanoPi-R2S Plus gmac2io arm64: dts: rockchip: add pwm-fan for NanoPC-T6 arm64: dts: rockchip: Add rk3576 evb2 board dt-bindings: arm: rockchip: Add rk3576 evb2 board arm64: dts: rockchip: Add overlay for FriendlyElec HD702E arm64: dts: rockchip: Move RK3399 eDP pinctrl to boards arm64: dts: rockchip: add overlay for qnap-ts133 device revision arm64: dts: rockchip: add overlay for qnap-ts233 device revision arm64: dts: rockchip: add overlay for qnap-ts433 device revision ... Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-03-21x86/um: fix vDSO installationThomas Weißschuh2-2/+2
The generic vDSO installation logic used by 'make vdso_install' requires that $(vdso-install-y) is defined by the top-level architecture Makefile and that it contains a path relative to the root of the tree. For UML neither of these is satisfied. Move the definition of $(vdso-install-y) to a place which is included by the arch/um/Makefile and use the full relative path. Fixes: f1c2bb8b9964 ("um: implement a x86_64 vDSO") Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://patch.msgid.link/20260318-um-vdso-install-v1-1-26a4ca5c4210@weissschuh.net Signed-off-by: Johannes Berg <johannes.berg@intel.com>
generated by cgit (git 2.54.0.dirty) at 2026-10-01 03:21:22 +0000