summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2026-04-01KVM: arm64: vgic-v5: Transfer edge pending state to ICH_PPI_PENDRx_EL2Marc Zyngier1-1/+4
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 Zyngier1-0/+10
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 Zyngier1-2/+2
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 Zyngier1-4/+4
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 Zyngier1-2/+2
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 Zyngier1-6/+6
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 Zyngier1-2/+9
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 Sajna1-0/+2
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 Sajna3-0/+18
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 Sajna2-6/+75
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 Sajna1-0/+17
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 Dahan1-0/+28
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 Brown1-0/+14
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 Sajna3-0/+53
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 Sajna1-0/+16
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 Sajna1-0/+4
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 Sajna1-4/+12
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 Sajna1-4/+12
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 Sajna1-62/+62
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 Vesa1-0/+16
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 Axboe1-1/+9
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 Axboe4-28/+70
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 Bergmann15-114/+289
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 Biesheuvel5-0/+57
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 Berger3-1/+17
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 Berger1-1/+2
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 Zohar4-16/+24
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 Zohar2-2/+2
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 Zohar5-56/+90
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 Siewior1-5/+2
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 Li1-3/+3
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-01powercap: intel_rapl: Consolidate PL4 and PMU support flags into rapl_defaultsKuppuswamy Sathyanarayanan2-47/+38
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>
2026-04-01powercap: intel_rapl: Move MSR primitives to MSR driverKuppuswamy Sathyanarayanan2-105/+99
MSR-specific RAPL primitives differ from those used by TPMI and MMIO interfaces. Keeping them in the common driver requires interface-specific handling logic and makes the common layer unnecessarily complex. Move the MSR primitive definitions and associated bitmasks into the MSR interface driver. This change includes: 1. Move MSR-specific bitmask definitions to RAPL MSR driver. 2. Add MSR-local struct rapl_primitive_info instance and assign it to priv->rpi during MSR probe. 3. Remove the primitive assignment logic from rapl_config() in the common driver. No functional changes are intended. Co-developed-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Link: https://patch.msgid.link/20260331211950.3329932-7-sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-04-01thermal: intel: int340x: processor: Move MMIO primitives to MMIO driverKuppuswamy Sathyanarayanan2-1/+72
MMIO-specific primitives differ from those used by the TPMI interface. The MSR and MMIO interfaces shared the same primitives in the common driver, but MMIO does not require many MSR-specific entries (like PSYS). Keeping these in the common driver does not add any value and requires interface-specific handling logic that makes the common layer unnecessarily complex. Move the MMIO primitive definitions and associated bitmasks into the MMIO interface driver. This change includes: 1. Add MMIO-local struct rapl_primitive_info instance without MSR-specific entries and assign it to priv->rpi during MMIO initialization. 2. Remove the RAPL MMIO case from rapl_config() in the common driver. No functional changes are intended. Co-developed-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Link: https://patch.msgid.link/20260331211950.3329932-6-sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-04-01powercap: intel_rapl: Move TPMI primitives to TPMI driverKuppuswamy Sathyanarayanan2-51/+53
TPMI-specific RAPL primitives differ from those used by MSR and MMIO interfaces. Keeping them in the common RAPL driver requires interface-specific handling logic and makes the common layer unnecessarily complex. Move the TPMI primitive definitions and associated bitmasks into the TPMI interface driver. This change includes: 1. Move TPMI-specific bitmask definitions from intel_rapl_common.c to intel_rapl_tpmi.c. 2. Add TPMI-local struct rapl_primitive_info instance and assign it to priv->rpi during TPMI probe. 3. Remove the RAPL TPMI related definitions from the common driver. No functional changes are intended. Co-developed-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Link: https://patch.msgid.link/20260331211950.3329932-5-sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-04-01powercap: intel_rapl: Move primitive info to header for interface driversKuppuswamy Sathyanarayanan2-32/+32
RAPL primitive information varies across different RAPL interfaces (MSR, TPMI, MMIO). Keeping them in the common code adds no benefit, but requires interface-specific handling logic and makes the common layer unnecessarily complex. Move the primitive info infrastructure to the shared header to allow interface drivers to configure RAPL primitives. Specific changes: 1. Move struct rapl_primitive_info, enum unit_type, and PRIMITIVE_INFO_INIT macro to intel_rapl.h. 2. Change the @rpi field in struct rapl_if_priv from void * to struct rapl_primitive_info * to improve type safety and eliminate unnecessary casts. No functional changes. This is a preparatory refactoring to allow interface drivers to supply their own RAPL primitive settings. Co-developed-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Link: https://patch.msgid.link/20260331211950.3329932-4-sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-04-01powercap: intel_rapl: Remove unused macro definitionsKuppuswamy Sathyanarayanan1-8/+0
Remove the following unused macro definitions from the RAPL common driver: * DOMAIN_STATE_INACTIVE and DOMAIN_STATE_POWER_LIMIT_SET * IOSF_CPU_POWER_BUDGET_CTL_BYT and IOSF_CPU_POWER_BUDGET_CTL_TNG * MAX_PRIM_NAME No functional changes. Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Link: https://patch.msgid.link/20260331211950.3329932-3-sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-04-01powercap: intel_rapl: Move MSR default settings into MSR interface driverKuppuswamy Sathyanarayanan2-228/+250
MSR-specific RAPL defaults differ from those used by the TPMI interface. The MMIO and MSR interfaces shared the same rapl_defaults pointer in the common driver, but MMIO does not require the CPU-specific variations needed by MSR. Keeping these in the common driver adds unnecessary complexity and MSR-specific initialization. Move MSR defaults and CPU matching into the MSR interface driver. Moves ----- * Move rapl_check_unit_atom(), set_floor_freq_atom(), and rapl_compute_time_window_atom() into intel_rapl_msr.c. * Move MSR unit-field GENMASK definitions and local constants. * Move all MSR-related rapl_defaults tables and the CPU-ID matching logic (rapl_ids[]) into the MSR driver. * Move iosf_mbi dependencies (floor-frequency control and related MBI register definitions) as they are MSR-platform specific. Modifications ------------- * Replace the common driver's platform-device manual alloc/add sequence with platform_device_register_data() in the MSR driver to pass matching rapl_defaults as platform_data. * Update MSR driver probe to assign pdev->dev.platform_data to priv->defaults. * Update Atom helper functions to use rp->lead_cpu directly for MSR reads/writes instead of the generic get_rid(). * Update Atom floor frequency logic to access defaults via the package private data pointer. * Convert MSR device creation from fs_initcall() to module_init(). This preserves existing enumeration behavior as the driver was already using module_init(). * Since rapl_ids need to exist after boot, remove __initconst specifier. No functional changes are expected. Co-developed-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20260331211950.3329932-2-sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-04-01cpuidle: clean up dead dependencies on CPU_IDLE in KconfigJulian Braha3-4/+2
The Kconfig in the parent directory already has the first 'if CPU_IDLE' gating the inclusion of this Kconfig, meaning that the 'depends on CPUIDLE' statements in these config options are effectively dead code. Leave the 'if CPU_IDLE...endif' condition, and remove the individual 'depends on' statements in Kconfig.mips and Kconfig.powerpc This dead code was found by kconfirm, a static analysis tool for Kconfig. Signed-off-by: Julian Braha <julianbraha@gmail.com> [ rjw: Subject and changelog edits ] Link: https://patch.msgid.link/20260331074920.41269-1-julianbraha@gmail.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-04-01cpufreq: clean up dead code in KconfigJulian Braha1-3/+2
There is already an 'if CPU_FREQ' condition wrapping these config options, making the 'depends on' statement for each a duplicate dependency (dead code). Leave the outer 'if CPU_FREQ...endif' and remove the individual 'depends on' statement from each option. This dead code was found by kconfirm, a static analysis tool for Kconfig. Signed-off-by: Julian Braha <julianbraha@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw: Subject and changelog edits ] Link: https://patch.msgid.link/20260331074242.39986-1-julianbraha@gmail.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-04-01cpufreq: Allocate QoS freq_req objects with policyViresh Kumar2-42/+17
A recent change exposed a bug in the error path: if freq_qos_add_request(boost_freq_req) fails, min_freq_req may remain a valid pointer even though it was never successfully added. During policy teardown, this leads to an unconditional call to freq_qos_remove_request(), triggering a WARN. The current design allocates all three freq_req objects together, making the lifetime rules unclear and error handling fragile. Simplify this by allocating the QoS freq_req objects at policy allocation time. The policy itself is dynamically allocated, and two of the three requests are always needed anyway. This ensures consistent lifetime management and eliminates the inconsistent state in failure paths. Reported-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Fixes: 6e39ba4e5a82 ("cpufreq: Add boost_freq_req QoS request") Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com> Tested-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Link: https://patch.msgid.link/a293f29d841b86c51f34699c6e717e01858d8ada.1774933424.git.viresh.kumar@linaro.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-04-01ASoC: tegra: Add error logging for probe and callback failuresMark Brown15-96/+73
Sheetal <sheetal@nvidia.com> says: Resend pending v3 patches with fixes and add remaining dev_err_probe() conversions. Patch 1 replaces v3 patch 03/14 (ADMAIF). Patch 2 replaces v3 patch 09/14 (OPE/PEQ/MBDRC). Patch 3 is new - adds regmap init conversions across 10 drivers. Patch 4 is new - adds clock error conversions in tegra_asoc_machine.
2026-04-01ASoC: tegra: Use dev_err_probe() in tegra_asoc_machine probeSheetal1-12/+9
Use dev_err_probe() for clock errors in the tegra_asoc_machine probe path. Signed-off-by: Sheetal <sheetal@nvidia.com> Link: https://patch.msgid.link/20260401112500.4076861-5-sheetal@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-01ASoC: tegra: Use dev_err_probe() for regmap init failuresSheetal10-40/+30
Use dev_err_probe() for regmap init failures in Tegra audio driver probe paths. Signed-off-by: Sheetal <sheetal@nvidia.com> Link: https://patch.msgid.link/20260401112500.4076861-4-sheetal@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-01ASoC: tegra: Use dev_err_probe() in OPE, PEQ and MBDRC driversSheetal3-32/+24
Log errors in the Tegra210 OPE, PEQ and MBDRC probe paths using dev_err_probe(). Drop redundant dev_err() at tegra210_peq_regmap_init() and tegra210_mbdrc_regmap_init() call sites in ope_probe() since these functions already log errors internally. Signed-off-by: Sheetal <sheetal@nvidia.com> Link: https://patch.msgid.link/20260401112500.4076861-3-sheetal@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-01ASoC: tegra: Add error logging in tegra210_admaif driverSheetal1-12/+10
Log errors in the Tegra210 ADMAIF probe and runtime callback paths. Drop redundant dev_err() at tegra_isomgr_adma_register() call site since it already logs errors internally. Signed-off-by: Sheetal <sheetal@nvidia.com> Link: https://patch.msgid.link/20260401112500.4076861-2-sheetal@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-01Merge tag 'counter-fixes-for-7.0' of ↵Greg Kroah-Hartman1-32/+35
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/wbg/counter into char-misc-linus William writes: Counter fixes for 7.0 Two fixes for rz-mut3-cnt: synchronize runtime PM usage count to toggle state of the counter, and set counter->parent during probe to ensure the current dev pointer is accessed during driver operation. * tag 'counter-fixes-for-7.0' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/wbg/counter: counter: rz-mtu3-cnt: do not use struct rz_mtu3_channel's dev member counter: rz-mtu3-cnt: prevent counter from being toggled multiple times
2026-04-01KVM: arm64: Don't hold 'vm_table_lock' across guest page reclaimWill Deacon1-5/+6
Now that the teardown of a VM cannot be finalised as long as a reference is held on the VM, rework __pkvm_reclaim_dying_guest_page() to hold a reference to the dying VM rather than take the global 'vm_table_lock' during the reclaim operation. Signed-off-by: Will Deacon <will@kernel.org> Link: https://patch.msgid.link/20260331155056.28220-4-will@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: Allow get_pkvm_hyp_vm() to take a reference to a dying VMWill Deacon1-7/+1
Now that completion of the teardown path requires a refcount of zero for the target VM, we can allow get_pkvm_hyp_vm() to take a reference on a dying VM, which is necessary to unshare pages with a non-protected VM during the teardown process itself. Note that vCPUs belonging to a dying VM cannot be loaded and pages can only be reclaimed from a protected VM (via __pkvm_reclaim_dying_guest_page()) if the target VM is in the dying state. Signed-off-by: Will Deacon <will@kernel.org> Link: https://patch.msgid.link/20260331155056.28220-3-will@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: Prevent teardown finalisation of referenced 'hyp_vm'Will Deacon1-14/+18
Destroying a 'hyp_vm' with an elevated referenced count in __pkvm_finalize_teardown_vm() is only going to lead to tears. In preparation for allowing limited references to be acquired on dying VMs during the teardown process, factor out the handle-to-vm logic for the teardown path and reuse it for both the 'start' and 'finalise' stages of the teardown process. Signed-off-by: Will Deacon <will@kernel.org> Link: https://patch.msgid.link/20260331155056.28220-2-will@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-06-12 17:36:57 +0300