summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-04-01KVM: arm64: set_id_regs: Allow GICv3 support to be set at runtimeMarc Zyngier
set_id_regs creates a GIC3 guest when possible, and then proceeds to write the ID registers as if they were not affected by the presence of a GIC. As it turns out, ID_AA64PFR1_EL1 is the proof of the contrary. KVM now makes a point in exposing the GIC support to the guest, no matter what userspace says (userspace such as QEMU is known to write silly things at times). Accommodate for this level of nonsense by teaching set_id_regs about fields that are mutable, and only compare registers that have been re-sanitised first. Reported-by: Mark Brown <broonie@kernel.org> Link: https://patch.msgid.link/20260401103611.357092-17-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: Don't advertises GICv3 in ID_PFR1_EL1 if AArch32 isn't supportedMarc Zyngier
Although the AArch32 ID regs are architecturally UNKNOWN when AArch32 isn't supported at any EL, KVM makes a point in making them RAZ. Therefore, advertising GICv3 in ID_PFR1_EL1 must be gated on AArch32 being supported at least at EL0. Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: a258a383b9177 ("KVM: arm64: gic-v5: Sanitize ID_AA64PFR2_EL1.GCIE") Reported-by: Mark Brown <broonie@kernel.org> Tested-by: Mark Brown <broonie@kernel.org> Link: https://patch.msgid.link/20260401103611.357092-16-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: Correctly plumb ID_AA64PFR2_EL1 into pkvm idreg handlingMarc Zyngier
While we now compute ID_AA64PFR2_EL1 to a glorious 0, we never use that data and instead return the 0 that corresponds to an allocated idreg. Not a big deal, but we might as well be consistent. Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: 5aefaf11f9af5 ("KVM: arm64: gic: Hide GICv5 for protected guests") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-15-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: Move GICv5 timer PPI validation into timer_irqs_are_valid()Marc Zyngier
Userspace can set the timer PPI numbers way before a GIC has been created, leading to odd behaviours on GICv5 as we'd accept non architectural PPI numbers. Move the v5 check into timer_irqs_are_valid(), which aligns the behaviour with the pre-v5 GICs, and is also guaranteed to run only once a GIC has been configured. Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: 9491c63b6cd7b ("KVM: arm64: gic-v5: Enlighten arch timer for GICv5") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-14-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: Remove evaluation of timer state in kvm_cpu_has_pending_timer()Marc Zyngier
The vgic-v5 code added some evaluations of the timers in a helper funtion (kvm_cpu_has_pending_timer()) that is called to determine whether the vcpu can wake-up. But looking at the timer there is wrong: - we want to see timers that are signalling an interrupt to the vcpu, and not just that have a pending interrupt - we already have kvm_arch_vcpu_runnable() that evaluates the state of interrupts - kvm_cpu_has_pending_timer() really is about WFIT, as the timeout does not generate an interrupt, and is therefore distinct from the point above As a consequence, revert these changes and teach vgic_v5_has_pending_ppi() about checking for pending HW interrupts instead. Fixes: 9491c63b6cd7b ("KVM: arm64: gic-v5: Enlighten arch timer for GICv5") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-13-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: Kill arch_timer_context::direct fieldMarc Zyngier
The newly introduced arch_timer_context::direct field is a bit pointless, as it is always set on timers that are... err... direct, while we already have a way to get to that by doing a get_map() operation. Additionally, this field is: - only set when get_map() is called - never cleared and the single point where it is actually checked doesn't call get_map() at all. At this stage, it is probably better to just kill it, and rely on get_map() to give us the correct information. Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: 9491c63b6cd7b ("KVM: arm64: gic-v5: Enlighten arch timer for GICv5") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-12-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: vgic-v5: Correctly set dist->ready once initialisedMarc Zyngier
kvm_vgic_map_resources() targetting a v5 model results in vgic->dist_ready never being set. This doesn't result in anything really bad, only some more heavy locking as we go and re-init something for no good reason. Rejig the code to correctly set the ready flag in all non-failing cases. Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: f4d37c7c35769 ("KVM: arm64: gic-v5: Create and initialise vgic_v5") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-11-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: vgic-v5: Make the effective priority mask a strict limitMarc Zyngier
The way the effective priority mask is compared to the priority of an interrupt to decide whether to wake-up or not, is slightly odd, and breaks at the limits. This could result in spurious wake-ups that are undesirable. Make the computed priority mask comparison a strict inequality, so that interrupts that have the same priority as the mask are not signalled. Fixes: 933e5288fa971 ("KVM: arm64: gic-v5: Check for pending PPIs") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-10-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: vgic-v5: Cast vgic_apr to u32 to avoid undefined behavioursMarc Zyngier
Passing a u64 to __builtin_ctz() is odd, and requires some digging to figure out why this construct is indeed safe as long as the HW is correct. But it is much easier to make it clear to the compiler by casting the u64 into an intermediate u32, and be done with the UD. Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: 933e5288fa971 ("KVM: arm64: gic-v5: Check for pending PPIs") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-9-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: vgic-v5: Transfer edge pending state to ICH_PPI_PENDRx_EL2Marc Zyngier
While it is perfectly correct to leave the pending state of a level interrupt as is when queuing it (it is, after all, only driven by the line), edge pending state must be transfered, as nothing will lower it. Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: 4d591252bacb2 ("KVM: arm64: gic-v5: Implement PPI interrupt injection") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-8-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: vgic-v5: Hold config_lock while finalizing GICv5 PPIsMarc Zyngier
Finalizing the PPI state is done without holding any lock, which means that two vcpus can race against each other and have one zeroing the state while another one is setting it, or even maybe using it. Fixing this is done by: - holding the config lock while performing the initialisation - checking if SW_PPI has already been advertised, meaning that we have already completed the initialisation once Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: 8f1fbe2fd2792 ("KVM: arm64: gic-v5: Finalize GICv5 PPIs and generate mask") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-7-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: Account for RESx bits in __compute_fgt()Marc Zyngier
When computing Fine Grained Traps, it is preferable to account for the reserved bits. The HW will most probably ignore them, unless the bits have been repurposed to do something else. Use caution, and fold our view of the reserved bits in, Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: c259d763e6b09 ("KVM: arm64: Account for RES1 bits in DECLARE_FEAT_MAP() and co") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260401103611.357092-6-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: Fix writeable mask for ID_AA64PFR2_EL1Marc Zyngier
The writeable mask for fields in ID_AA64PFR2_EL1 has been accidentally inverted, which isn't a very good idea. Restore the expected polarity. Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: a258a383b9177 ("KVM: arm64: gic-v5: Sanitize ID_AA64PFR2_EL1.GCIE") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-5-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01arm64: Fix field references for ICH_PPI_DVIR[01]_EL2Marc Zyngier
The ICH_PPI_DVIR[01]_EL2 registers should refer to the ICH_PPI_DVIRx_EL2 fields, instead of ICH_PPI_DVIx_EL2. Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: 2808a8337078f ("arm64/sysreg: Add remaining GICv5 ICC_ & ICH_ sysregs for KVM support") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-4-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: Don't skip per-vcpu NV initialisationMarc Zyngier
Some GICv5-related rework have resulted in the NV sanitisation of registers being skipped for secondary vcpus, which is a pretty bad idea. Hoist the NV init early so that it is always executed. Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: cbd8c958be54a ("KVM: arm64: Return early from kvm_finalize_sys_regs() if guest has run") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-3-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: vgic: Don't reset cpuif/redist addresses at finalize timeMarc Zyngier
Although we are OK with rewriting idregs at finalize time, resetting the guest's cpuif (GICv3) or redistributor (GICv3) addresses once we start running the guest is a pretty bad idea. Move back this initialisation to vgic creation time. Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: a258a383b9177 ("KVM: arm64: gic-v5: Sanitize ID_AA64PFR2_EL1.GCIE") Link: https://patch.msgid.link/20260323174713.3183111-1-maz@kernel.org Link: https://patch.msgid.link/20260401103611.357092-2-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01arm64: dts: qcom: sdm845-lg-common: Add chassis-typePaul Sajna
The sdm845-lg devices are all phones, therefore handset chassis Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Paul Sajna <sajattack@postmarketos.org> Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-12-87217b15fefb@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-01arm64: dts: qcom: sdm845-lg: Add wifi nodesPaul Sajna
Wi-Fi now works with this patch, relevant firmware and qcom,snoc-host-cap-skip-quirk qcom,snoc-host-cap-skip-quirk has not been approved/merged in mainline, so it is not included here. ath10k_snoc 18800000.wifi: qmi chip_id 0x30214 chip_family 0x4001 board_id 0xff soc_id 0x40030001 ath10k_snoc 18800000.wifi: qmi fw_version 0x20060285 fw_build_timestamp 2020-10-12 23:35 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c4-00645-QCAHLSWMTPLZ-1.336037.2 ath10k_snoc 18800000.wifi: wcn3990 hw1.0 target 0x00000008 chip_id 0x00000000 sub 0000:0000 ath10k_snoc 18800000.wifi: kconfig debug 1 debugfs 1 tracing 0 dfs 0 testmode 0 ath10k_snoc 18800000.wifi: firmware ver api 5 features wowlan,mgmt-tx-by-reference,non-bmi crc32 b3d4b790 ath10k_snoc 18800000.wifi: htt-ver 3.83 wmi-op 4 htt-op 3 cal file max-sta 32 raw 0 hwcrypto 1 ath10k_snoc 18800000.wifi: invalid MAC address; choosing random Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Paul Sajna <sajattack@postmarketos.org> Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-11-87217b15fefb@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-01arm64: dts: qcom: sdm845-lg-judyln: Add display panelPaul Sajna
Also include other supporting msm drm nodes, gpio and backlight Co-developed-by: Amir Dahan <system64fumo@tuta.io> Signed-off-by: Amir Dahan <system64fumo@tuta.io> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Paul Sajna <sajattack@postmarketos.org> Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-10-87217b15fefb@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-01arm64: dts: qcom: sdm845-lg-judyln: Add lab/ibbPaul Sajna
These regulators are required for the LCD Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Paul Sajna <sajattack@postmarketos.org> Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-9-87217b15fefb@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-01arm64: dts: qcom: sdm845-lg-common: Add LEDsAmir Dahan
Add the multicolor status LED in the phone's notch. Signed-off-by: Amir Dahan <system64fumo@tuta.io> Reviewed-by: Pavel Machek <pavel@ucw.cz> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Paul Sajna <sajattack@postmarketos.org> Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-8-87217b15fefb@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-01arm64: dts: qcom: sdm845-lg-judyln: Add battery and chargerChristopher Brown
Values based on lineageos kernel https://github.com/LineageOS/android_kernel_lge_sdm845/blob/lineage-22.2/arch/arm64/boot/dts/lge/sdm845-battery/LGE_BLT39_LGC_3000mAh.dtsi Signed-off-by: Christopher Brown <crispybrown@gmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Paul Sajna <sajattack@postmarketos.org> Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-7-87217b15fefb@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-01arm64: dts: qcom: sdm845-lg: Add uarts and BluetoothPaul Sajna
uart9 is debug serial on USB SBU1/2 UART RX is SBU1 and UART TX is SBU2 of the USB-C port). 1.8V Logic Level Tested using pololu usb07a https://www.pololu.com/product/2585 and CH340 USB-UART uart6 is bluetooth Bluetooth: hci0: setting up wcn399x Bluetooth: hci0: QCA Product ID :0x0000000a Bluetooth: hci0: QCA SOC Version :0x40010214 Bluetooth: hci0: QCA ROM Version :0x00000201 Bluetooth: hci0: QCA Patch Version:0x00000001 Bluetooth: hci0: QCA controller version 0x02140201 Bluetooth: hci0: QCA Downloading qca/crbtfw21.tlv Bluetooth: hci0: QCA Downloading qca/judyln/crnv21.bin Bluetooth: hci0: QCA setup on UART is completed Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Paul Sajna <sajattack@postmarketos.org> Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-6-87217b15fefb@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-01arm64: dts: qcom: sdm845-lg-common: Enable qups and their dma controllersPaul Sajna
Qualcomm serial communicators required for i2c, serial, and spi Signed-off-by: Paul Sajna <sajattack@postmarketos.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-5-87217b15fefb@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-01arm64: dts: qcom: sdm845-lg-common: Enable venusPaul Sajna
Qualcomm video en/de-coder Signed-off-by: Paul Sajna <sajattack@postmarketos.org> Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-4-87217b15fefb@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-01arm64: dts: qcom: sdm845-lg-judyp: Define firmware paths for judypPaul Sajna
For consistency with judyln and new naming scheme for firmware Signed-off-by: Paul Sajna <sajattack@postmarketos.org> Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-3-87217b15fefb@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-01arm64: dts: qcom: sdm845-lg-judyln: Add firmware nodes, change pathPaul Sajna
Add paths for Qualcomm firmware, including: ipa, modem, venus, gpu GPU and bluetooth are confirmed working, others may need more testing/fixes But regardless they will need the firmware paths specified here and firmware added upstream before they will work, so might as well get started on it now. Signed-off-by: Paul Sajna <sajattack@postmarketos.org> Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-2-87217b15fefb@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-01arm64: dts: qcom: sdm845-lg-common: Sort nodes and propertiesPaul Sajna
Improve adherance to style guidelines below: https://docs.kernel.org/devicetree/bindings/dts-coding-style.html Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Paul Sajna <sajattack@postmarketos.org> Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-1-87217b15fefb@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-01arm64: dts: qcom: glymur-crd: Enable DisplayPort supportAbel Vesa
The two Type-C ports found on Glymur CRD are DisplayPort alternate mode capable. Everything is in place already for the USB, but for DisplayPort the controllers need to be enabled. So enable the related DisplayPort controller for each of these two ports. Also define the supported link frequencies for each output. Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260330-glymur-enable-displayport-v1-1-1543ad6dac3a@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-01io_uring/bpf_filters: retain COW'ed settings on parse failuresJens Axboe
If io_parse_restrictions() fails, it ends up clearing any restrictions currently set. The intent is only to clear whatever it already applied, but it ends up clearing everything, including whatever settings may have been applied in a copy-on-write fashion already. Ensure that those are retained. Link: https://lore.kernel.org/io-uring/CAK8a0jzF-zaO5ZmdOrmfuxrhXuKg5m5+RDuO7tNvtj=kUYbW7Q@mail.gmail.com/ Reported-by: antonius <bluedragonsec2023@gmail.com> Fixes: ed82f35b926b ("io_uring: allow registration of per-task restrictions") Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-04-01io_uring: protect remaining lockless ctx->rings accesses with RCUJens Axboe
Commit 96189080265e addressed one case of ctx->rings being potentially accessed while a resize is happening on the ring, but there are still a few others that need handling. Add a helper for retrieving the rings associated with an io_uring context, and add some sanity checking to that to catch bad uses. ->rings_rcu is always valid, as long as it's used within RCU read lock. Any use of ->rings_rcu or ->rings inside either ->uring_lock or ->completion_lock is sane as well. Do the minimum fix for the current kernel, but set it up such that this basic infra can be extended for later kernels to make this harder to mess up in the future. Thanks to Junxi Qian for finding and debugging this issue. Cc: stable@vger.kernel.org Fixes: 79cfe9e59c2a ("io_uring/register: add IORING_REGISTER_RESIZE_RINGS") Reviewed-by: Junxi Qian <qjx1298677004@gmail.com> Tested-by: Junxi Qian <qjx1298677004@gmail.com> Link: https://lore.kernel.org/io-uring/20260330172348.89416-1-qjx1298677004@gmail.com/ Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-04-01Merge tag 'arm-soc/for-7.1/devicetree' of ↵Arnd Bergmann
https://github.com/Broadcom/stblinux into soc/dt This pull request contains Broadcom ARM-based SoCs Device Tree updates for 7.1, please pull the following: - Rafal provides a complete description of the PCIe Root Complex nodes in order to silence a number of dtc warnings - Rosen provides the necessary NVMEM properties to allow describing the WAN device MAC address from NVRAM, also adds better LEDs, USB GPIOs and Wi-Fi buttons for the Linksys EA9200 router - Linus completes the BCA devices description by adding the I2C block and fixing interrupts for the DMA block on 63138 and 6878 * tag 'arm-soc/for-7.1/devicetree' of https://github.com/Broadcom/stblinux: ARM: dts: BCM5301X: EA9200: specify partitions ARM: dts: BCM5301X: EA9200: add LEDs ARM: dts: BCM5301X: EA9200: add USB GPIOs ARM: dts: BCM5301X: EA9200: add WiFi button ARM: dts: broadcom: bcm2835-rpi: Move non simple-bus nodes to root level ARM: dts: bcm63148: Add I2C block ARM: dts: bcm63138: Add I2C block ARM: dts: bcm6878: Add I2C bus block ARM: dts: bcm6855: Add I2C bus blocks ARM: dts: bcm6846: Add I2C bus block ARM: dts: bcm63138: Fix DMA IRQ ARM: dts: bcm6878: Fix PL081 DMA block IRQ ARM: dts: BCM5301X: AC5300: set WAN MAC from nvram ARM: dts: BCM5301X: AC3100: set WAN MAC from nvram ARM: dts: BCM5301X: panamera: set WAN MAC from nvram ARM: dts: BCM5301X: EA9200: set WAN MAC from nvram ARM: dts: BCM5301X: add root pcie bridges ARM: dts: BCM5301X: Drop extra NAND controller compatible ARM: dts: BCM5301X: Describe PCIe controllers fully Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-04-01arm64: Use static call trampolines when kCFI is enabledArd Biesheuvel
Implement arm64 support for the 'unoptimized' static call variety, which routes all calls through a trampoline that performs a tail call to the chosen function, and wire it up for use when kCFI is enabled. This works around an issue with kCFI and generic static calls, where the prototypes of default handlers such as __static_call_nop() and __static_call_ret0() don't match the expected prototype of the call site, resulting in kCFI false positives [0]. Since static call targets may be located in modules loaded out of direct branching range, this needs an ADRP/LDR pair to load the branch target into R16 and a branch-to-register (BR) instruction to perform an indirect call. Unlike on x86, there is no pressing need on arm64 to avoid indirect calls at all cost, but hiding it from the compiler as is done here does have some benefits: - the literal is located in .rodata, which gives us the same robustness advantage that code patching does; - no D-cache pollution from fetching hash values from .text sections. From an execution speed PoV, this is unlikely to make any difference at all. Cc: Sami Tolvanen <samitolvanen@google.com> Cc: Sean Christopherson <seanjc@google.com> Cc: Kees Cook <kees@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Will McVicker <willmcvicker@google.com> Reported-by: Carlos Llamas <cmllamas@google.com> Closes: https://lore.kernel.org/all/20260311225822.1565895-1-cmllamas@google.com/ [0] Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2026-04-01evm: Enforce signatures version 3 with new EVM policy 'bit 3'Stefan Berger
Enable the configuration of EVM so that it requires that asymmetric signatures it accepts are of version 3 (sigv3). To enable this, introduce bit 3 (value 0x0008) that the user may write to EVM's securityfs policy configuration file 'evm' for sigv3 enforcement. Mention bit 3 in the documentation. Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2026-04-01integrity: Allow sigv3 verification on EVM_XATTR_PORTABLE_DIGSIGStefan Berger
Allow sigv3 verification on EVM_XATTR_PORTABLE_DIGSIG on RSA, ECDSA, ECRDSA, and SM2 signatures. Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2026-04-01ima: add support to require IMA sigv3 signaturesMimi Zohar
Defining a policy rule with the "appraise_type=imasig" option allows either v2 or v3 signatures. Defining an IMA appraise rule with the "appraise_type=sigv3" option requires a file sigv3 signature. Define a new appraise type: IMA_SIGV3_REQUIRED Example: appraise func=BPRM_CHECK appraise_type=sigv3 Tested-by: Stefan Berger <stefanb@linux.ibm.com> Acked-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2026-04-01ima: add regular file data hash signature version 3 supportMimi Zohar
Instead of directly verifying the signature of a file data hash, signature v3 verifies the signature of the ima_file_id structure containing the file data hash. To disambiguate the signature usage, the ima_file_id structure also includes the hash algorithm and the type of data (e.g. regular file hash or fs-verity root hash). Tested-by: Stefan Berger <stefanb@linux.ibm.com> Acked-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2026-04-01ima: Define asymmetric_verify_v3() to verify IMA sigv3 signaturesMimi Zohar
Define asymmetric_verify_v3() to calculate the hash of the struct ima_file_id, before calling asymmetric_verify() to verify the signature. Move and update the existing calc_file_id_hash() function with a simpler, self contained version. In addition to the existing hash data and hash data length arguments, also pass the hash algorithm. Suggested-by: Stefan Berger <stefanb@linux.ibm.com> Tested-by: Stefan Berger <stefanb@linux.ibm.com> Acked-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2026-04-01genirq/affinity: Remove cpus_read_lock() while reading cpu_possible_maskSebastian Andrzej Siewior
cpu_possible_mask is set early during boot based on information from the firmware. After that it remains read only and is never changed. Therefore there is no need to acquire the CPU-hotplug lock while reading it. Remove cpus_read_*() while accessing cpu_possible_mask. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260401121334.xeMOSC1v@linutronix.de
2026-04-01cpufreq: governor: fix double free in cpufreq_dbs_governor_init() error pathGuangshuo Li
When kobject_init_and_add() fails, cpufreq_dbs_governor_init() calls kobject_put(&dbs_data->attr_set.kobj). The kobject release callback cpufreq_dbs_data_release() calls gov->exit(dbs_data) and kfree(dbs_data), but the current error path then calls gov->exit(dbs_data) and kfree(dbs_data) again, causing a double free. Keep the direct kfree(dbs_data) for the gov->init() failure path, but after kobject_init_and_add() has been called, let kobject_put() handle the cleanup through cpufreq_dbs_data_release(). Fixes: 4ebe36c94aed ("cpufreq: Fix kobject memleak") Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: All applicable <stable@vger.kernel.org> Link: https://patch.msgid.link/20260401024535.1395801-1-lgs201920130244@gmail.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-04-01drm/i915/rom: Use intel_de for SPI ROM register accessVille Syrjälä
Since we moved intel_rom.c back into the display code, just use intel_de_{read,write}() for the register accesses. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260331154259.24600-13-ville.syrjala@linux.intel.com
2026-04-01drm/i915/mchbar: Use intel_de_read*() for MCHBAR register accessesVille Syrjälä
Replace the naked intel_uncore_read*() with intel_de_read*() in the MCHBAR code. v2: Rebase due to intel_uncore_read64_2x32() Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260331154259.24600-12-ville.syrjala@linux.intel.com
2026-04-01drm/i915/vrr: Use intel_de_read64_2x32()Ville Syrjälä
Replace the pointless use of intel_de_read64_2x32_volatile() with the simpler intel_de_read64_2x32(). Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260331154259.24600-11-ville.syrjala@linux.intel.com
2026-04-01drm/i915/de: Add a simple intel_de_read64_2x32()Ville Syrjälä
intel_de_read64_2x32_volatile() is a complex beast because it needs to deal with volatile register values. For simpler cases we can simply do a pair normal intel_de_read()s. My main reason for hating overuse of intel_de_read64_2x32_volatile() is that it makes register tracepoints confusing. It always does three accesses in the somewhat weird udw,ldw,udw order, confusing the reader of the trace. Much more clear if we just observe the two reads in the natural little endian order. We also have no non-volatile use case where the LDW and UDW are stored in non-consecutive registers, so we can just pass along a single register offset. v2: Put the function arguments on one line (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260331154259.24600-10-ville.syrjala@linux.intel.com
2026-04-01drm/i915/de: s/intel_de_read64_2x32()/intel_de_read64_2x32_volatile()/Ville Syrjälä
The raison d'etre of intel_de_read64_2x32() is that it can handle registers where volatile values are split across two registers. I don't like that it's being used needlessly. Rename it to intel_de_read64_2x32_volatile() to make it more clear when it should be used. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260331154259.24600-9-ville.syrjala@linux.intel.com
2026-04-01drm/i915/de: Add intel_de_read16()Ville Syrjälä
We'll need a replacement for intel_uncore_read16() in order to untangle intel_mchbar_read16() from uncore. As with the 8 bit counterpart this doesn't need to work on modern platforms so we can forgo all the DMC wakelock stuff and whatnot. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260331154259.24600-8-ville.syrjala@linux.intel.com
2026-04-01drm/i915/mchbar: Use intel_mchbar_read*() instead of intel_uncore_read*()Ville Syrjälä
Replace all the naked intel_uncore_read*() accesses to MCHBAR registers with the dedicated intel_mchbar_read*(). v2: Rebase due to the intel_mchbar_read64_2x32() rename Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260331154259.24600-7-ville.syrjala@linux.intel.com
2026-04-01drm/i915/mchbar: Use intel_mchbar_read() instead of intel_de_read()Ville Syrjälä
We are doing a few accesses to MCHBAR registers with intel_de_read(). Use the dedicated intel_mchbar_read() instead. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260331154259.24600-6-ville.syrjala@linux.intel.com
2026-04-01drm/i915/mchbar: WARN when accessing non-MCHBAR registers via ↵Ville Syrjälä
intel_mchbar_read*() The intel_mchbar_read*() functions should only be used for accessing MCHBAR registers. Warn if someone tries to use them for other registers. I suppose we could even have a dedicated type for MCHBAR registers. But that is true for many other special register types as well, and so far we haven't bothered adding any special types apart from i915_mcr_reg_t. v2: Print the register offset (Jani) Mention i915_mcr_reg_t (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260331154259.24600-5-ville.syrjala@linux.intel.com
2026-04-01powercap: intel_rapl: Consolidate PL4 and PMU support flags into rapl_defaultsKuppuswamy Sathyanarayanan
Currently, PL4 and MSR-based RAPL PMU support are detected using separate CPU ID tables (pl4_support_ids and pmu_support_ids) in the MSR driver probe path. This creates a maintenance burden since adding a new CPU requires updates in two places: the rapl_ids table and one or both of these capability tables. Consolidate PL4 and PMU capability information directly into struct rapl_defaults by adding msr_pl4_support and msr_pmu_support flags. This allows per-CPU capability to be expressed in a single place alongside other per-CPU defaults, eliminating the duplicate CPU ID tables entirely. No functional changes are intended. Co-developed-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Link: https://patch.msgid.link/20260331211950.3329932-8-sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-15 17:35:45 +0000