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>
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
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
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
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
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
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
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
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>
MCHBAR registers are a bit special in that:
- we access them through the mirror
- the mirror is read only on HSW+
- the mirror requires the actual MCHBAR to be enabled in device 0:0.0
- the mirror is gone on MTL+
So I'd prefer to treat MCHBAR registers as a bit special in
the code as well, and do all accesses to them via dedicated
functions. Prodive such functions in the form of
intel_mchbar_read*().
v2: Put the function arguments on one line
No intel_uncore_read64() on xe, use intel_uncore_read64_2x32()
Name the new function intel_mchbar_read64_2x32() as well
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-3-ville.syrjala@linux.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>
