summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2025-07-16riscv: dts: starfive: jh7110-common: add status power led nodeE Shattow
Add status power led node for StarFive VisionFive2 and variant boards. Signed-off-by: E Shattow <e@freeshell.de> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-07-16riscv: dts: starfive: jh7110-milkv-mars sort propertiesE Shattow
Improve style with node property order sort of common properties before vendor prefixes Signed-off-by: E Shattow <e@freeshell.de> Acked-by: Emil Renner Berthing <emil.renner.berthing@canonical.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-07-16riscv: ftrace: Properly acquire text_mutex to fix a race conditionAlexandre Ghiti
As reported by lockdep, some patching was done without acquiring text_mutex, so there could be a race when mapping the page to patch since we use the same fixmap entry. Reported-by: Han Gao <rabenda.cn@gmail.com> Reported-by: Vivian Wang <wangruikang@iscas.ac.cn> Reported-by: Yao Zi <ziyao@disroot.org> Closes: https://lore.kernel.org/linux-riscv/aGODMpq7TGINddzM@pie.lan/ Tested-by: Yao Zi <ziyao@disroot.org> Tested-by: Han Gao <rabenda.cn@gmail.com> Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20250711-alex-fixes-v2-1-d85a5438da6c@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-07-16riscv: Stop considering R_RISCV_NONE as bad relocationsAlexandre Ghiti
Even though those relocations should not be present in the final vmlinux, there are a lot of them. And since those relocations are considered "bad", they flood the compilation output which may hide some legitimate bad relocations. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Tested-by: Ron Economos <re@w6rz.net> Link: https://lore.kernel.org/r/20250710-dev-alex-riscv_none_bad_relocs_v1-v1-1-758f2fcc6e75@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-07-16arm64: cacheinfo: Provide helper to compress MPIDR value into u32James Morse
Filesystems like resctrl use the cache-id exposed via sysfs to identify groups of CPUs. The value is also used for PCIe cache steering tags. On DT platforms cache-id is not something that is described in the device-tree, but instead generated from the smallest MPIDR of the CPUs associated with that cache. The cache-id exposed to user-space has historically been 32 bits. MPIDR values may be larger than 32 bits. MPIDR only has 32 bits worth of affinity data, but the aff3 field lives above 32bits. The corresponding lower bits are masked out by MPIDR_HWID_BITMASK and contain an SMT flag and Uni-Processor flag. Swizzzle the aff3 field into the bottom 32 bits and using that. In case more affinity fields are added in the future, the upper RES0 area should be checked. Returning a value greater than 32 bits from this helper will cause the caller to give up on allocating cache-ids. Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Link: https://lore.kernel.org/r/20250711182743.30141-4-james.morse@arm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-16s390/pai_crypto: Rename PAI Crypto event 4210Thomas Richter
The PAI crypto event number 4210 is named PCC_COMPUTE_LAST_BLOCK_CMAC_USING_ENCRYPTED_AES_256A According to the z16 and z17 Principle of Operation documents SA22-7832-13 and SA22-7832-14 the event is named PCC_COMPUTE_LAST_BLOCK_CMAC_USING_ENCRYPTED_AES_256 without a trailing 'A'. Adjust this event name. Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Reviewed-by: Sumanth Korikkar <sumanthk@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2025-07-15KVM: arm64: Tighten the definition of FEAT_PMUv3p9Marc Zyngier
The current definition of FEAT_PMUv3p9 doesn't check for the lack of an IMPDEF PMU, which is encoded as 0b1111, but considered unsigned. Use the recently introduced helper to address the issue (which is harmless, as KVM never advertises an IMPDEF PMU). Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714115503.3334242-6-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-15KVM: arm64: Convert MDCR_EL2 to config-driven sanitisationMarc Zyngier
As for other registers, convert the determination of the RES0 bits affecting MDCR_EL2 to be driven by a table extracted from the 2025-06 JSON drop Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714115503.3334242-5-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-15KVM: arm64: Convert SCTLR_EL1 to config-driven sanitisationMarc Zyngier
As for other registers, convert the determination of the RES0 bits affecting SCTLR_EL1 to be driven by a table extracted from the 2025-06 JSON drop Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714115503.3334242-4-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-15KVM: arm64: Convert TCR2_EL2 to config-driven sanitisationMarc Zyngier
As for other registers, convert the determination of the RES0 bits affecting TCR2_EL2 to be driven by a table extracted from the 2025-06 JSON drop. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714115503.3334242-3-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-15arm64: sysreg: Add THE/ASID2 controls to TCR2_ELxMarc Zyngier
FEAT_THE and FEAT_ASID2 add new controls to the TCR2_ELx registers. Add them to the register descriptions. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714115503.3334242-2-maz@kernel.org [ fix whitespace ] Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-15KVM: arm64: Advertise FGT2 registers to userspaceMarc Zyngier
While a guest is able to use the FEAT_FGT2 registers, we're missing them being exposed to userspace. Add them to the (very long) list. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714122634.3334816-9-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-15KVM: arm64: Condition FGT registers on feature availabilityMarc Zyngier
We shouldn't expose the FEAT_FGT registers unconditionally. Make them dependent on FEAT_FGT being actually advertised to the guest. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714122634.3334816-8-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-15KVM: arm64: Expose GICv3 EL2 registers via KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGSMarc Zyngier
Expose all the GICv3 EL2 registers through the usual GICv3 save/restore interface, making it possible for a VMM to access the EL2 state. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714122634.3334816-7-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-15KVM: arm64: Let GICv3 save/restore honor visibility attributeMarc Zyngier
The GICv3 save/restore code never needed any visibility attribute, but that's about to change. Make vgic_v3_has_cpu_sysregs_attr() check the visibility in case a register is hidden. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714122634.3334816-6-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-15KVM: arm64: Define helper for ICH_VTR_EL2Marc Zyngier
Move the computation of the ICH_VTR_EL2 value to a common location, so that it can be reused by the save/restore code. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714122634.3334816-5-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-15KVM: arm64: Define constant value for ICC_SRE_EL2Marc Zyngier
Move the bag of bits defining the value of ICC_SRE_EL2 to a common spot so that it can be reused by the save/restore code. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714122634.3334816-4-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-15KVM: arm64: Don't advertise ICH_*_EL2 registers through GET_ONE_REGMarc Zyngier
It appears that exposing the GICv3 EL2 registers through the usual sysreg interface is not consistent with the way we expose the EL1 registers. The latter are exposed via the GICv3 device interface instead, and there is no reason why the EL2 registers should get a different treatement. Hide the registers from userspace until the GICv3 code grows the required infrastructure. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714122634.3334816-3-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-15KVM: arm64: Make RVBAR_EL2 accesses UNDEFMarc Zyngier
We always expose a virtual CPU that has EL3 when NV is enabled, irrespective of EL3 being actually implemented in HW. Therefore, as per the architecture, RVBAR_EL2 must UNDEF, since EL2 is not the highest implemented exception level. This is consistent with RMR_EL2 also triggering an UNDEF. Adjust the handling of RVBAR_EL2 accordingly. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714122634.3334816-2-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-15KVM: arm64: Commit exceptions from KVM_SET_VCPU_EVENTS immediatelyOliver Upton
syzkaller has found that it can trip a warning in KVM's exception emulation infrastructure by repeatedly injecting exceptions into the guest. While it's unlikely that a reasonable VMM will do this, further investigation of the issue reveals that KVM can potentially discard the "pending" SEA state. While the handling of KVM_GET_VCPU_EVENTS presumes that userspace-injected SEAs are realized immediately, in reality the emulated exception entry is deferred until the next call to KVM_RUN. Hack-a-fix the immediate issues by committing the pending exceptions to the vCPU's architectural state immediately in KVM_SET_VCPU_EVENTS. This is no different to the way KVM-injected exceptions are handled in KVM_RUN where we potentially call __kvm_adjust_pc() before returning to userspace. Reported-by: syzbot+4e09b1432de3774b86ae@syzkaller.appspotmail.com Reported-by: syzbot+1f6f096afda6f4f8f565@syzkaller.appspotmail.com Reviewed-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-15KVM: VMX: Ensure unused kvm_tdx_capabilities fields are zeroed outSean Christopherson
Zero-allocate the kernel's kvm_tdx_capabilities structure and copy only the number of CPUID entries from the userspace structure. As is, KVM doesn't ensure kernel_tdvmcallinfo_1_{r11,r12} and user_tdvmcallinfo_1_r12 are zeroed, i.e. KVM will reflect whatever happens to be in the userspace structure back at userspace, and thus may report garbage to userspace. Zeroing the entire kernel structure also provides better semantics for the reserved field. E.g. if KVM extends kvm_tdx_capabilities to enumerate new information by repurposing bytes from the reserved field, userspace would be required to zero the new field in order to get useful information back (because older KVMs without support for the repurposed field would report garbage, a la the aforementioned tdvmcallinfo bugs). Fixes: 61bb28279623 ("KVM: TDX: Get system-wide info about TDX module on initialization") Suggested-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Reported-by: Xiaoyao Li <xiaoyao.li@intel.com> Closes: https://lore.kernel.org/all/3ef581f1-1ff1-4b99-b216-b316f6415318@intel.com Tested-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Link: https://lore.kernel.org/r/20250714221928.1788095-1-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-07-15arm64: dts: rockchip: Drop regulator-compatible property on rk3399Diederik de Haas
The regulator-compatible property has never existed in the regulator/fcs,fan53555.yaml binding, so drop it. This fixes the following DTB validation warnings: Unevaluated properties are not allowed ('regulator-compatible' was unexpected) Signed-off-by: Diederik de Haas <didi.debian@cknow.org> Link: https://lore.kernel.org/r/20250709132323.128757-11-didi.debian@cknow.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-07-15arm64: dts: rockchip: Drop unneeded address+size-cells on px30Diederik de Haas
On nodes with compatible "rockchip,px30-usb2phy-grf", the #address-cells and #size-cells are required and consequently their child nodes should have unit addresses. That is not the case for the px30-pmugrf and px30-grf nodes, so remove them there. This fixes the following DTB validation warnings: unnecessary #address-cells/#size-cells without "ranges", "dma-ranges" or child "reg" property Signed-off-by: Diederik de Haas <didi.debian@cknow.org> Link: https://lore.kernel.org/r/20250709132323.128757-10-didi.debian@cknow.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-07-15arm64: dts: rockchip: Fix LCD panel port on rk3566-pinetab2Diederik de Haas
The MIPI DSI connector on the PineTab2 only has 1 port with 1 endpoint, so drop the unit-address properties. While at it, move 'rotation' property to its proper sorting position. This fixes the following DTB validation warnings: node has a unit name, but no reg or ranges property Signed-off-by: Diederik de Haas <didi.debian@cknow.org> Link: https://lore.kernel.org/r/20250709132323.128757-9-didi.debian@cknow.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-07-15arm64: dts: rockchip: Move mipi_out node on rk3399 haikou demo dtsoDiederik de Haas
According to the DTS coding style [1] referenced nodes should be sorted alpha-numerically so move mipi_out to be after mipi_in_panel. [1] https://www.kernel.org/doc/html/latest/devicetree/bindings/dts-coding-style.html#order-of-nodes Signed-off-by: Diederik de Haas <didi.debian@cknow.org> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Link: https://lore.kernel.org/r/20250709132323.128757-8-didi.debian@cknow.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-07-15arm64: dts: rockchip: Simplify mipi_out endpoint on rk3399 RP64 dtsoDiederik de Haas
The only thing actually added here is a single endpoint on mipi_out, which is already defined in rk3399-base.dtsi, so it's simpler to just reference that phandle, which allows the removal of several properties. Signed-off-by: Diederik de Haas <didi.debian@cknow.org> Link: https://lore.kernel.org/r/20250709132323.128757-7-didi.debian@cknow.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-07-15arm64: dts: rockchip: Simplify edp endpoints on several rk3399 boardsDiederik de Haas
The only thing actually added here is a single endpoint on edp_out, which is already defined in rk3399-base.dtsi, so it's simpler to just reference that phandle, which allows the removal of several properties. This fixes the following DTB validation warnings: graph node has single child node 'endpoint@0', #address-cells/#size-cells are not necessary Signed-off-by: Diederik de Haas <didi.debian@cknow.org> Link: https://lore.kernel.org/r/20250709132323.128757-6-didi.debian@cknow.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-07-15arm64: dts: rockchip: Simplify VOP port definition on rk3328Diederik de Haas
When there's only 1 endpoint, there is no need for a unit-address and removing that allows removing of related properties as well. This fixes the following DTB validation warnings: graph node has single child node 'endpoint@0', #address-cells/#size-cells are not necessary Signed-off-by: Diederik de Haas <didi.debian@cknow.org> Link: https://lore.kernel.org/r/20250709132323.128757-5-didi.debian@cknow.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-07-15Merge tag 'kvm-riscv-fixes-6.16-2' of https://github.com/kvm-riscv/linux ↵Paolo Bonzini
into HEAD KVM/riscv fixes for 6.16, take #2 - Disable vstimecmp before exiting to user-space - Move HGEI[E|P] CSR access to IMSIC virtualization
2025-07-15Merge tag 'kvmarm-fixes-6.16-6' of ↵Paolo Bonzini
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 fixes for 6.16, take #6 - Fix use of u64_replace_bits() in adjusting the guest's view of MDCR_EL2.HPMN.
2025-07-15arm64: smp: Fix pNMI setup after GICv5 reworkMarc Zyngier
Breno reports that pNMIs are not behaving the way they should since they were reworked for GICv5. Turns out we feed the IRQ number to the pNMI helper instead of the IPI number -- not a good idea. Fix it by providing the correct number (duh). Fixes: ba1004f861d16 ("arm64: smp: Support non-SGIs for IPIs") Reported-by: Breno Leitao <leitao@debian.org> Suggested-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-07-15Merge tag 'soc-fixes-6.16-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull SoC fixes from Arnd Bergmann: "There are 18 devicetree fixes for three arm64 plaforms: Qualcomm Snapdragon, Rockchips and NXP i.MX. These get updated to more correctly describe the hardware, fixing issues with: - real-time clock on Snapdragon based laptops - SD card detection, PCI probing and HDMI/DDC communication on Rockchips - ethernet and SPI probing on certain i.MX based boards - a regression with the i.MX watchdog Aside from the devicetree fixes, there are two additional fixes for the merged ASPEED LPC snoop driver that saw some changes in 6.16, and one additional driver enabled in arm64 defconfig to fix CPU frequency scaling" * tag 'soc-fixes-6.16-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (21 commits) arm64: dts: freescale: imx8mm-verdin: Keep LDO5 always on soc: aspeed: lpc-snoop: Don't disable channels that aren't enabled soc: aspeed: lpc-snoop: Cleanup resources in stack-order arm64: dts: imx95: Correct the DMA interrupter number of pcie0_ep arm64: dts: rockchip: Add missing fan-supply to rk3566-quartz64-a arm64: dts: rockchip: use cs-gpios for spi1 on ringneck arm64: dts: add big-endian property back into watchdog node arm64: dts: imx95-15x15-evk: fix the overshoot issue of NETC arm64: dts: imx95-19x19-evk: fix the overshoot issue of NETC arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5 arm64: dts: imx8mp-venice-gw74xx: fix TPM SPI frequency arm64: dts: imx8mp-venice-gw73xx: fix TPM SPI frequency arm64: dts: imx8mp-venice-gw72xx: fix TPM SPI frequency arm64: dts: imx8mp-venice-gw71xx: fix TPM SPI frequency arm64: dts: qcom: x1e80100: describe uefi rtc offset arm64: dts: qcom: sc8280xp-x13s: describe uefi rtc offset arm64: defconfig: Enable Qualcomm CPUCP mailbox driver arm64: dts: rockchip: Add cd-gpios for sdcard detect on Cool Pi 4B arm64: dts: rockchip: Add cd-gpios for sdcard detect on Cool Pi CM5 arm64: dts: rockchip: Adjust the HDMI DDC IO driver strength for rk3588 ...
2025-07-15arm64: dts: allwinner: a523: enable Mali GPU for all boardsMikhail Kalashnikov
All devices based on the A523/A527/H728/T527 processors contain a G57 MC1 GPU. Enable the DT nodes for this GPU and specify a regulator that supplies power to the SoC's VDD_GPU pins. The other parameters are set in the SoC dtsi, so are board independent. Signed-off-by: Mikhail Kalashnikov <iuncuim@gmail.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Link: https://patch.msgid.link/20250711035730.17507-4-iuncuim@gmail.com Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-07-15arm64: dts: allwinner: a523: add Mali GPU nodeMikhail Kalashnikov
The Allwinner A523 SoC features the Mali-G57 MC1 GPU, which belongs to the Mali Valhall (v9) family. There is a power domain specifically for this GPU that needs to be enabled to utilize it. To enable in a specific device, we need to enable the gpu node and specify the “mali-supply” regulator additionally in the device tree. Signed-off-by: Mikhail Kalashnikov <iuncuim@gmail.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Link: https://patch.msgid.link/20250711035730.17507-3-iuncuim@gmail.com Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-07-15arm64: dts: allwinner: a523: Add power controller device nodesChen-Yu Tsai
The A523 SoC family has two power controllers, one based on the existing PPU, and one newer one based on ARM's PCK-600. Add device nodes for both of them. Reviewed-by: Andre Przywara <andre.przywara@arm.com> Link: https://patch.msgid.link/20250712074021.805953-6-wens@kernel.org Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-07-15Merge branch 'dt' of ↵Chen-Yu Tsai
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm into sunxi/dt-for-6.17 Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-07-15mips: loongson3_defconfig: Update HD-audio configsTakashi Iwai
Since the reorganization of HD-audio drivers, Realtek driver has been split. Update to the new Kconfigs to catch up. Fixes: aeeb85f26c3b ("ALSA: hda: Split Realtek HD-audio codec driver") Link: https://patch.msgid.link/20250715075237.28476-3-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-07-15arm: multi_v7_defconfig: Update HD-audio configsTakashi Iwai
Since the reorganization of HD-audio drivers, Realtek and HDMI codec drivers have been split. Update to the new Kconfigs to catch up. Fixes: aeeb85f26c3b ("ALSA: hda: Split Realtek HD-audio codec driver") Fixes: 73cd0490819d ("ALSA: hda/hdmi: Split vendor codec drivers") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/20250715170422.5162c666@canb.auug.org.au Link: https://patch.msgid.link/20250715075237.28476-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-07-15KVM: x86: Reject KVM_SET_TSC_KHZ vCPU ioctl for TSC protected guestKai Huang
Reject KVM_SET_TSC_KHZ vCPU ioctl if guest's TSC is protected and not changeable by KVM, and update the documentation to reflect it. For such TSC protected guests, e.g. TDX guests, typically the TSC is configured once at VM level before any vCPU are created and remains unchanged during VM's lifetime. KVM provides the KVM_SET_TSC_KHZ VM scope ioctl to allow the userspace VMM to configure the TSC of such VM. After that the userspace VMM is not supposed to call the KVM_SET_TSC_KHZ vCPU scope ioctl anymore when creating the vCPU. The de facto userspace VMM Qemu does this for TDX guests. The upcoming SEV-SNP guests with Secure TSC should follow. Note, TDX support hasn't been fully released as of the "buggy" commit, i.e. there is no established ABI to break. Fixes: adafea110600 ("KVM: x86: Add infrastructure for secure TSC") Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Nikunj A Dadhania <nikunj@amd.com> Link: https://lore.kernel.org/r/71bbdf87fdd423e3ba3a45b57642c119ee2dd98c.1752444335.git.kai.huang@intel.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-07-15arm64/gcs: Don't call gcs_free() when releasing task_structMark Brown
Currently we call gcs_free() when releasing task_struct but this is redundant, it attempts to deallocate any kernel managed userspace GCS which should no longer be relevant and resets values in the struct we're in the process of freeing. By the time arch_release_task_struct() is called the mm will have been disassociated from the task so the check for a mm in gcs_free() will always be false, for threads that are exiting leaving the mm active deactivate_mm() will have been called previously and freed any kernel managed GCS. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250714-arm64-gcs-release-task-v2-1-8a83cadfc846@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2025-07-15arm64: dts: rockchip: Move dsi address+size-cells from SoC to rk3399 boardsDiederik de Haas
The #address-cells and #size-cells properties are not useful on the DSI controller node; they are only useful/required on ports and panel(s). So remove them from the controller node and add them where actually needed on the various rk3399 based boards. This fixes the following DTB validation warnings: unnecessary #address-cells/#size-cells without "ranges", "dma-ranges" or child "reg" property Signed-off-by: Diederik de Haas <didi.debian@cknow.org> Link: https://lore.kernel.org/r/20250709132323.128757-3-didi.debian@cknow.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-07-15arm64: dts: rockchip: Move dsi address+size-cells from SoC to px30 boardsDiederik de Haas
The #address-cells and #size-cells properties are not useful on the DSI controller node; they are only useful/required on ports and panel(s). So remove them from the controller node and add them where actually needed on the various px30 based boards, which includes rk3326. This fixes the following DTB validation warnings: unnecessary #address-cells/#size-cells without "ranges", "dma-ranges" or child "reg" property Signed-off-by: Diederik de Haas <didi.debian@cknow.org> Link: https://lore.kernel.org/r/20250709132323.128757-2-didi.debian@cknow.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-07-15arm64: dts: rockchip: Fix UART DMA support for RK3528Jonas Karlman
Trying to use UART2 DMA for Bluetooth on ArmSoM Sige1 result in tx timeout when using dma-names = "tx", "rx" as required by the dt-binding: Bluetooth: hci0: command 0x0c03 tx timeout Bluetooth: hci0: BCM: Reset failed (-110) Change the dmas order to fix UART DMA support on RK3528. With this fixed Bluetooth can be loaded using DMA on ArmSoM Sige1: Bluetooth: hci0: BCM: chip id 159 Bluetooth: hci0: BCM: features 0x0f Bluetooth: hci0: BCM4362A2 Bluetooth: hci0: BCM4362A2 (000.017.017) build 0000 Bluetooth: hci0: BCM4362A2 'brcm/BCM4362A2.hcd' Patch Bluetooth: hci0: BCM: features 0x0f Bluetooth: hci0: BCM43752A2 UART 37.4MHz Ampak AP6398 sLNA iLNA CL1 [Version: 1091.1173] Bluetooth: hci0: BCM4362A2 (000.017.017) build 1173 Fixes: ab6fcb58aedf ("arm64: dts: rockchip: Add UART DMA support for RK3528") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Link: https://lore.kernel.org/r/20250709210831.3170458-1-jonas@kwiboo.se Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-07-15arm64: dts: rockchip: Add reset button to NanoPi R5SDiederik de Haas
The NanoPi R5S LTS version has a reset button, which is connected via GPIO. Note that the non-LTS version does not have the reset button and therefore on page 19 of the schematic version 2204 it is marked 'NC', but it is connected on the LTS version. Signed-off-by: Diederik de Haas <didi.debian@cknow.org> Link: https://lore.kernel.org/r/20250711142138.197445-1-didi.debian@cknow.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-07-15arm64: dts: rockchip: Add rtc0 alias for NanoPi R5S + R5CDiederik de Haas
The RTC_HCTOSYS_DEVICE module defaults to rtc0 and should (highly) preferable be assigned to a battery backed RTC module as it is used to (re)initialize the system clock. The R5S and R5C have a connector for a RTC battery which is used by HYM8563 RTC. Both devices also have another RTC from the rk809 PMIC. To make sure the HYM8563 is always assigned rtc0, add an alias for it. Signed-off-by: Diederik de Haas <didi.debian@cknow.org> Link: https://lore.kernel.org/r/20250713161723.270963-1-didi.debian@cknow.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-07-15x86/apic: Move apic_update_irq_cfg() call to apic_update_vector()Neeraj Upadhyay
All callers of apic_update_vector() also call apic_update_irq_cfg() after it. So, move the apic_update_irq_cfg() call to apic_update_vector(). No functional change intended. Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250709033242.267892-18-Neeraj.Upadhyay@amd.com
2025-07-15x86/sev: Work around broken noinstr on GCCArd Biesheuvel
Forcibly disable KCSAN for the sev-nmi.c source file, which only contains functions annotated as 'noinstr' but is emitted with calls to KCSAN instrumentation nonetheless. E.g., vmlinux.o: error: objtool: __sev_es_nmi_complete+0x58: call to __kcsan_check_access() leaves .noinstr.text section make[2]: *** [/usr/local/google/home/ardb/linux/scripts/Makefile.vmlinux_o:72: vmlinux.o] Error 1 Fixes: a3cbbb4717e1 ("x86/boot: Move SEV startup code into startup/") Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/20250714073402.4107091-2-ardb+git@google.com
2025-07-15x86/hyperv: Expose hv_map_msi_interrupt()Stanislav Kinsburskii
Move some of the logic of hv_irq_compose_irq_message() into hv_map_msi_interrupt(). Make hv_map_msi_interrupt() a globally-available helper function, which will be used to map PCI interrupts when running in the root partition. Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com> Reviewed-by: Roman Kisel <romank@linux.microsoft.com> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Link: https://lore.kernel.org/r/1752261532-7225-3-git-send-email-nunodasneves@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Message-ID: <1752261532-7225-3-git-send-email-nunodasneves@linux.microsoft.com>
2025-07-15Drivers: hv: Use nested hypercall for post message and signal eventNuno Das Neves
When running nested, these hypercalls must be sent to the L0 hypervisor or VMBus will fail. Remove hv_do_nested_hypercall() and hv_do_fast_nested_hypercall8() altogether and open-code these cases, since there are only 2 and all they do is add the nested bit. Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com> Reviewed-by: Roman Kisel <romank@linux.microsoft.com> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Link: https://lore.kernel.org/r/1752261532-7225-2-git-send-email-nunodasneves@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Message-ID: <1752261532-7225-2-git-send-email-nunodasneves@linux.microsoft.com>
2025-07-14xtensa: ptrace: Use USER_REGSET_NOTE_TYPE() to specify regset note namesDave Martin
Instead of having the core code guess the note name for each regset, use USER_REGSET_NOTE_TYPE() to pick the correct name from elf.h. Signed-off-by: Dave Martin <Dave.Martin@arm.com> Cc: Chris Zankel <chris@zankel.net> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Kees Cook <kees@kernel.org> Cc: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Link: https://lore.kernel.org/r/20250701135616.29630-23-Dave.Martin@arm.com Signed-off-by: Kees Cook <kees@kernel.org>