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: 9491c63b6c ("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>
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: 9491c63b6c ("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>
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: 9491c63b6c ("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>
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: 933e5288fa ("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>
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: 8f1fbe2fd2 ("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>
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: a258a383b9 ("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>
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>
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>
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>
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>
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>
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>
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: ed82f35b92 ("io_uring: allow registration of per-task restrictions")
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Commit 9618908026 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: 79cfe9e59c ("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>
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
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAmnBjUcACgkQh9CWnEQH
BwQuSw//UCaVf2xSvFi8/XT6SQrfHvPEoZX0AUJWZG2SUVh1YkTJdsWBDVcQErLN
wwPxOK65q0a7XCA+BdRIAt9W5Boa5kO9zrwpwUXRKBupdbIDH67wxkQV2e73Ne3Z
FsBqTiOqlNCj8I7f4lzy/uP0/uHR5Nvyh4N4rHRj+hb20dFtOJOeXuMyo+FRIf+f
alVRFgLJi4P3SxCBsj6xUmR7p2l51MYhVZ/Ind0QwP9ZGBcOg0jfi4EUe07jnolb
twO9EFPVi/QMVHOnMGmJMz+oDX7Z882SjObB2FHOQPXDbsnONjfW782dwT8VObjM
vbsyfoH68AtTqbkZ/MXWEJeWYxVI/UQjrvRFkXVCqYpb3B7foo/fDCLi/5wnYMyE
BYza7w4DxVix4jwdfVeXcIb+wjVt7hrvNb6r+zIx5yHdA9oEiNfkJ1DajsCn50co
E/+XYq/9r9HxnkK3YkYr3ZLxvxqdXFLpnUaVtarWF3XQbDRqV5931kXfhp9VOO8T
wHHGiiHi7j2ELh9d38GMaZ95O3KV+3LUaTMHhGN7CKNi7G6gIGVRPVpmI9Ej7nc0
1g0fRKKKkPFA4aqG6FLWvYzjujoS9+ERRmYBPL3Zt2DXbEASCL2dw1p7eHM5fbu9
R56SXGhjc05e71DOs/yy5aHInC7RCCowMjVUC4IXRHRNBtAH3bw=
=ITzn
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmnNLNcACgkQmmx57+YA
GNlGeRAApKrehO59bFAZ3d+VW5rX6jhnY//egiYGse2j7NWsR9pgKTBSLHzSqwob
k5/ZDtrUxjWyt7AtNcB3FKa2eZPO6AZPZ0j0lIFPXARmOPJM+qy0aJHlgA3gFbht
adkz8nlpkVddS2dLlK+TXnmcLpmnAlBULZ4QbsvDyasWFKyacbm8z8ry+M6e4IXB
Y+1Jc/hPE8xIozMZ0OWL8yfh4rnCUsOolJif3kK5REX+rCrgOci7U3bEq93BLMb6
/jY1cSSxXXG7w3S/VPZgcqHTJpzMuKLUL0shH3j4rboaproBtvJ7i0280EGPVlwQ
cFDn6gi0GQ15eHinPsfYrGZCfXBDRYF2w/hiTivT0HHdwXcQIZCW5JaVqmhSf6SL
vWA1hfIZwgk4CyRa+ESHfG/vLRMPfqqEgjXpNc44sl8I0TRHubj+cHpqpZKYqYNY
DbE8WbcsEfCe4ROhMQu9nKIFTodgV8UhvxkcDuIhO5CslQaTyXiMMofWSBR6rdQN
ZIfoZ/WQYDgtzTlKCeIKryjE7Ii6vp55Th1Iyzj054qssSjVSH6/yfOCuXyfKZxP
tnznRvtZ2be422BchyPlTYIGErOWMfaJHZVnVmEnQ/DaosfSdh6PvJ1Aep1sF7UL
XIN7VWfQTbefrfFJXEU9dhKqCDEN4FFMVhkWRuIQJ0VMBqZZJYI=
=KEH/
-----END PGP SIGNATURE-----
Merge tag 'arm-soc/for-7.1/devicetree' of 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>
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>
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>
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>
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>
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>
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>
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
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: 4ebe36c94a ("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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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: 6e39ba4e5a ("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>
