* Re: [PATCH v5 2/4] cpupower-frequency-info.1: use the proper name of the --perf option
From: Shuah Khan @ 2026-03-24 23:11 UTC (permalink / raw)
To: Roberto Ricci, Thomas Renninger, Shuah Khan, John B. Wyatt IV,
John Kacur, linux-pm, linux-kernel, Shuah Khan
In-Reply-To: <32cdfa7a-765c-4f74-9839-d2e0b01435dc@linuxfoundation.org>
On 3/24/26 17:06, Shuah Khan wrote:
> On 3/24/26 16:39, Roberto Ricci wrote:
>> The cpupower-frequency-info(1) man page describes a '--perf' option.
>> Even though this form is accepted by the program, its proper name is
>> '--performance'.
>>
>> cpufreq-info.c:
>> {"performance", no_argument, NULL, 'c'},
>>
>> Signed-off-by: Roberto Ricci <io@r-ricci.it>
>> ---
>> tools/power/cpupower/man/cpupower-frequency-info.1 | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tools/power/cpupower/man/cpupower-frequency-info.1 b/tools/power/cpupower/man/cpupower-frequency-info.1
>> index 47fdd7218748..1173d4f31e69 100644
>> --- a/tools/power/cpupower/man/cpupower-frequency-info.1
>> +++ b/tools/power/cpupower/man/cpupower-frequency-info.1
>> @@ -53,7 +53,7 @@ human\-readable output for the \-f, \-w, \-s and \-y parameters.
>> \fB\-n\fR \fB\-\-no-rounding\fR
>> Output frequencies and latencies without rounding off values.
>> .TP
>> -\fB\-c\fR \fB\-\-perf\fR
>> +\fB\-c\fR \fB\-\-performance\fR
>
> I would keep perf and also add performance since --perf and --performance
> work - it is lot easier to type --perf
You can send just this one patch unless there are dependencies with
others.
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH v5 2/4] cpupower-frequency-info.1: use the proper name of the --perf option
From: Shuah Khan @ 2026-03-24 23:06 UTC (permalink / raw)
To: Roberto Ricci, Thomas Renninger, Shuah Khan, John B. Wyatt IV,
John Kacur, linux-pm, linux-kernel, Shuah Khan
In-Reply-To: <20260324223921.14317-3-io@r-ricci.it>
On 3/24/26 16:39, Roberto Ricci wrote:
> The cpupower-frequency-info(1) man page describes a '--perf' option.
> Even though this form is accepted by the program, its proper name is
> '--performance'.
>
> cpufreq-info.c:
> {"performance", no_argument, NULL, 'c'},
>
> Signed-off-by: Roberto Ricci <io@r-ricci.it>
> ---
> tools/power/cpupower/man/cpupower-frequency-info.1 | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/power/cpupower/man/cpupower-frequency-info.1 b/tools/power/cpupower/man/cpupower-frequency-info.1
> index 47fdd7218748..1173d4f31e69 100644
> --- a/tools/power/cpupower/man/cpupower-frequency-info.1
> +++ b/tools/power/cpupower/man/cpupower-frequency-info.1
> @@ -53,7 +53,7 @@ human\-readable output for the \-f, \-w, \-s and \-y parameters.
> \fB\-n\fR \fB\-\-no-rounding\fR
> Output frequencies and latencies without rounding off values.
> .TP
> -\fB\-c\fR \fB\-\-perf\fR
> +\fB\-c\fR \fB\-\-performance\fR
I would keep perf and also add performance since --perf and --performance
work - it is lot easier to type --perf
> Get performances and frequencies capabilities of CPPC, by reading it from hardware (only available on the hardware with CPPC).
> .TP
> .SH "REMARKS"
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH 4/9] interconnect: qcom: icc-rpm: allow overwriting get_bw callback
From: Dmitry Baryshkov @ 2026-03-24 22:51 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Georgi Djakov, Konrad Dybcio, Bjorn Andersson, Luca Weiss,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Brian Masney,
linux-arm-msm, linux-pm, devicetree, linux-kernel
In-Reply-To: <1376fad4-efc3-4b7d-bff8-9510ab0d3800@oss.qualcomm.com>
On Tue, Mar 24, 2026 at 12:34:35PM +0100, Konrad Dybcio wrote:
> On 3/24/26 12:14 AM, Dmitry Baryshkov wrote:
> > On Mon, Mar 23, 2026 at 11:32:33AM +0100, Konrad Dybcio wrote:
> >> On 3/23/26 2:17 AM, Dmitry Baryshkov wrote:
> >>> MSM8974 requires a separate get_bw callback, since on that platform
> >>> increasing the clock rate for some of the NoCs during boot may lead to
> >>> hangs. For the details see commit 9caf2d956cfa ("interconnect: qcom:
> >>> msm8974: Don't boost the NoC rate during boot").
> >>
> >> Is there a single specific bus where this causes an issue, or is
> >> setting *any* resource to INT_MAX problematic?
> >
> > I'd refer this to Luca. I didn't experiment that much (and also note,
> > this behaviour might be firmware-specific).
>
> In case anyone's interested, it _seems like_ it's
>
> (RPM_KEY_BW + RPM_BUS_MASTER_REQ/RPM_BUS_SLAVE_REQ) failing with certain
> nodes
Yes. And if you check, these nodes have QoS settings in the DT. Later
kernels have added a guard check (.qos.ap_owned) and dropped mas/slv IDs
for similar nodes.
> > My goal for this patchset was to port as close as possible. We can drop
> > the get_bw later, after enabling more interconnects, writing the QoS,
> > etc.
>
> That's fine
Rb?
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH v5 4/4] cpupower-info.1: describe the --perf-bias option
From: Roberto Ricci @ 2026-03-24 22:39 UTC (permalink / raw)
To: Thomas Renninger, Shuah Khan, John B. Wyatt IV, John Kacur,
linux-pm, linux-kernel
Cc: Roberto Ricci
In-Reply-To: <20260324223921.14317-1-io@r-ricci.it>
The cpupower-info(1) man page only mentions the short form of the
'--perf-bias' option in the synopsys, but the long form is not documented
and its effect is not explained.
cpupower-info.c:
{"perf-bias", optional_argument, NULL, 'b'},
Signed-off-by: Roberto Ricci <io@r-ricci.it>
---
tools/power/cpupower/man/cpupower-info.1 | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/tools/power/cpupower/man/cpupower-info.1 b/tools/power/cpupower/man/cpupower-info.1
index 340bcd0be7de..1f42d8c388a0 100644
--- a/tools/power/cpupower/man/cpupower-info.1
+++ b/tools/power/cpupower/man/cpupower-info.1
@@ -3,7 +3,7 @@
cpupower\-info \- Shows processor power related kernel or hardware configurations
.SH SYNOPSIS
.ft B
-.B cpupower info [ \-b ]
+.B cpupower info [\fIoptions\fP]
.SH DESCRIPTION
\fBcpupower info \fP shows kernel configurations or processor hardware
@@ -13,6 +13,13 @@ Some options are platform wide, some affect single cores. By default values
of core zero are displayed only. cpupower --cpu all cpuinfo will show the
settings of all cores, see cpupower(1) how to choose specific cores.
+.SH "OPTIONS"
+.LP
+.TP
+\fB\-b\fR \fB\-\-perf-bias\fR
+Gets the current performance bias value.
+.TP
+
.SH "SEE ALSO"
Options are described in detail in:
--
2.53.0
^ permalink raw reply related
* [PATCH v5 3/4] cpupower-frequency-info.1: document --boost and --epp options
From: Roberto Ricci @ 2026-03-24 22:39 UTC (permalink / raw)
To: Thomas Renninger, Shuah Khan, John B. Wyatt IV, John Kacur,
linux-pm, linux-kernel
Cc: Roberto Ricci
In-Reply-To: <20260324223921.14317-1-io@r-ricci.it>
`cpupower frequency-info` supports the '--boost' option since the program
was first added with commit 7fe2f6399a84 ("cpupowerutils - cpufrequtils
extended with quite some features"), but the man page lacks it.
'--epp' has been added with commit 5f567afc283f ("cpupower: Add support for
showing energy performance preference") but it has never been added to the
man page.
cpufreq-info.c:
{"boost", no_argument, NULL, 'b'},
...
{"epp", no_argument, NULL, 'z'},
Signed-off-by: Roberto Ricci <io@r-ricci.it>
---
tools/power/cpupower/man/cpupower-frequency-info.1 | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/tools/power/cpupower/man/cpupower-frequency-info.1 b/tools/power/cpupower/man/cpupower-frequency-info.1
index 1173d4f31e69..b0d69c9adcbd 100644
--- a/tools/power/cpupower/man/cpupower-frequency-info.1
+++ b/tools/power/cpupower/man/cpupower-frequency-info.1
@@ -32,6 +32,12 @@ Gets the currently used cpufreq policy.
\fB\-g\fR \fB\-\-governors\fR
Determines available cpufreq governors.
.TP
+\fB\-b\fR \fB\-\-boost\fR
+Gets the current boost state support.
+.TP
+\fB\-z\fR \fB\-\-epp\fR
+Gets the current EPP (energy performance preference).
+.TP
\fB\-r\fR \fB\-\-related\-cpus\fR
Determines which CPUs run at the same hardware frequency.
.TP
--
2.53.0
^ permalink raw reply related
* [PATCH v5 2/4] cpupower-frequency-info.1: use the proper name of the --perf option
From: Roberto Ricci @ 2026-03-24 22:39 UTC (permalink / raw)
To: Thomas Renninger, Shuah Khan, John B. Wyatt IV, John Kacur,
linux-pm, linux-kernel
Cc: Roberto Ricci
In-Reply-To: <20260324223921.14317-1-io@r-ricci.it>
The cpupower-frequency-info(1) man page describes a '--perf' option.
Even though this form is accepted by the program, its proper name is
'--performance'.
cpufreq-info.c:
{"performance", no_argument, NULL, 'c'},
Signed-off-by: Roberto Ricci <io@r-ricci.it>
---
tools/power/cpupower/man/cpupower-frequency-info.1 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/power/cpupower/man/cpupower-frequency-info.1 b/tools/power/cpupower/man/cpupower-frequency-info.1
index 47fdd7218748..1173d4f31e69 100644
--- a/tools/power/cpupower/man/cpupower-frequency-info.1
+++ b/tools/power/cpupower/man/cpupower-frequency-info.1
@@ -53,7 +53,7 @@ human\-readable output for the \-f, \-w, \-s and \-y parameters.
\fB\-n\fR \fB\-\-no-rounding\fR
Output frequencies and latencies without rounding off values.
.TP
-\fB\-c\fR \fB\-\-perf\fR
+\fB\-c\fR \fB\-\-performance\fR
Get performances and frequencies capabilities of CPPC, by reading it from hardware (only available on the hardware with CPPC).
.TP
.SH "REMARKS"
--
2.53.0
^ permalink raw reply related
* [PATCH v5 1/4] cpupower-idle-info.1: fix short option names
From: Roberto Ricci @ 2026-03-24 22:39 UTC (permalink / raw)
To: Thomas Renninger, Shuah Khan, John B. Wyatt IV, John Kacur,
linux-pm, linux-kernel
Cc: Roberto Ricci
In-Reply-To: <20260324223921.14317-1-io@r-ricci.it>
The cpupower-idle-info(1) man page describes '-f' as the short form of the
'--silent' option and '-e' as the short form of the '--proc' option.
But they are not correct:
$ cpupower idle-info -f
idle-info: invalid option -- 'f'
invalid or unknown argument
$ cpupower idle-info -e
idle-info: invalid option -- 'e'
invalid or unknown argument
The short form of '--silent' is actually '-s' and the short form of
'--proc' is actually '-o':
cpuidle-info.c:
{"silent", no_argument, NULL, 's'},
{"proc", no_argument, NULL, 'o'},
Signed-off-by: Roberto Ricci <io@r-ricci.it>
---
tools/power/cpupower/man/cpupower-idle-info.1 | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/power/cpupower/man/cpupower-idle-info.1 b/tools/power/cpupower/man/cpupower-idle-info.1
index 20b6345c53ad..b2f92aba5f5b 100644
--- a/tools/power/cpupower/man/cpupower-idle-info.1
+++ b/tools/power/cpupower/man/cpupower-idle-info.1
@@ -11,10 +11,10 @@ A tool which prints out per cpu idle information helpful to developers and inter
.SH "OPTIONS"
.LP
.TP
-\fB\-f\fR \fB\-\-silent\fR
+\fB\-s\fR \fB\-\-silent\fR
Only print a summary of all available C-states in the system.
.TP
-\fB\-e\fR \fB\-\-proc\fR
+\fB\-o\fR \fB\-\-proc\fR
deprecated.
Prints out idle information in old /proc/acpi/processor/*/power format. This
interface has been removed from the kernel for quite some time, do not let
--
2.53.0
^ permalink raw reply related
* [PATCH v5 0/4] cpupower: fix various man pages issues
From: Roberto Ricci @ 2026-03-24 22:39 UTC (permalink / raw)
To: Thomas Renninger, Shuah Khan, John B. Wyatt IV, John Kacur,
linux-pm, linux-kernel
Cc: Roberto Ricci
This patch series fixes a few issues with the cpupower manual pages,
such as missing or incorrect options and trailing whitespace.
Signed-off-by: Roberto Ricci <io@r-ricci.it>
---
Changes in v5:
- Drop whitespace removal patches
Link to v4: https://lore.kernel.org/linux-pm/20260324013543.4776-1-io@r-ricci.it/
Changes in v4:
- Remove Fixes tags from commit messages
- Fix issues reported by scripts/checkpatch.pl
- Add patches to trim whitespace from some files
- Add cover letter
Link to v3: https://lore.kernel.org/linux-pm/20260312102029.14980-1-io@r-ricci.it/
Changes in v3:
- Resend because v2 patches have been incorrectly sent as replies to
individual v1 messages.
Links to v2:
- https://lore.kernel.org/linux-pm/abH7pF9p8KxAsHIE@desktop0a/
- https://lore.kernel.org/linux-pm/abH9KsKbvyi-iceb@desktop0a/
- https://lore.kernel.org/linux-pm/abH9rMVuy8wmzgkG@desktop0a/
- https://lore.kernel.org/linux-pm/abH9_Jk-ckkJvsGb@desktop0a/
Changes in v2:
- More descriptive commit messages
Links to v1:
- https://lore.kernel.org/linux-pm/abHAZj9xwfDf5JVZ@desktop0a/
- https://lore.kernel.org/linux-pm/abHAdH-ggaxUugCy@desktop0a/
- https://lore.kernel.org/linux-pm/abHAhAg-6gaK0Qn7@desktop0a/
- https://lore.kernel.org/linux-pm/abHAkgiPg8VDpDoV@desktop0a/
---
Roberto Ricci (4):
cpupower-idle-info.1: fix short option names
cpupower-frequency-info.1: use the proper name of the --perf option
cpupower-frequency-info.1: document --boost and --epp options
cpupower-info.1: describe the --perf-bias option
tools/power/cpupower/man/cpupower-frequency-info.1 | 8 +++++++-
tools/power/cpupower/man/cpupower-idle-info.1 | 4 ++--
tools/power/cpupower/man/cpupower-info.1 | 9 ++++++++-
3 files changed, 17 insertions(+), 4 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [PATCH v6 3/9] cxl/region: Skip decoder reset on detach for autodiscovered regions
From: Alejandro Lucero Palau @ 2026-03-24 22:23 UTC (permalink / raw)
To: Dan Williams, Alison Schofield
Cc: Smita Koralahalli, linux-cxl, linux-kernel, nvdimm, linux-fsdevel,
linux-pm, Ard Biesheuvel, Vishal Verma, Ira Weiny,
Jonathan Cameron, Yazen Ghannam, Dave Jiang, Davidlohr Bueso,
Matthew Wilcox, Jan Kara, Rafael J . Wysocki, Len Brown,
Pavel Machek, Li Ming, Jeff Johnson, Ying Huang, Yao Xingtao,
Peter Zijlstra, Greg Kroah-Hartman, Nathan Fontenot, Terry Bowman,
Robert Richter, Benjamin Cheatham, Zhijian Li, Borislav Petkov,
Tomasz Wolski
In-Reply-To: <69c2ea1ea24e1_51621100a1@dwillia2-mobl4.notmuch>
On 3/24/26 19:46, Dan Williams wrote:
> Alison Schofield wrote:
<snip>
> Like I replied to Alejandro it is not a dependency for the type-2 series
> [1]. It *is* a fix for the issue reported by PJ, but it can go in
> independent of the base type-2 work as a standalone capability.
>
> [1]: http://lore.kernel.org/69b8b9181bafd_452b100cb@dwillia2-mobl4.notmuch
I'm afraid I do not understand what you mean here.
<snip>
> Just like the decoder LOCK bit the preservation setting is a decoder
> property, not a region property. Region auto-assembly is then just an
> automatic way to set that decoder policy.
>
> So, no, I would not expect a new region flag for this policy.
Could it be acceptable an accelerator having the option of locking its
HDM if not already done by the BIOS?
<snip>
> Appreciate you pulling this together. I want to land type-2 with the
> existing expectation that unload is always destructive then circle back
As I said, v22 had that destructive behavior, but v23 kept the HDM
committed, as that was what you asked for.
Last v24 has only the support for dealing with committed decoders, what
is the expectation from current BIOS (Intel and AMD) if a Type2 device
is found at boot time. I got now some BIOS versions which lock the HDM
decoder for a Type2 device making impossible any destructive action. The
reason for only supporting this case is to have a chance to be in time
for 7.1 with the basic (but good enough) support as there are issues
with the changes to create a region which will need all to agree on how
to solve them, and unlikely before 7.1 window closes.
> to address this additional detail because it is more than just decoder
> policy that needs to be managed. The type-2 driver may need help finding
> its platform firmware configured address range if a device reset
> destroyed the decoder settings.
>
And again, this problem should be addressed, IMO, as a follow-up.
^ permalink raw reply
* Re: [PATCH v4 3/6] cpupower-frequency-info.1: trim trailing whitespace
From: Shuah Khan @ 2026-03-24 22:09 UTC (permalink / raw)
To: Roberto Ricci
Cc: Thomas Renninger, John B. Wyatt IV, John Kacur, linux-pm,
linux-kernel, Shuah Khan
In-Reply-To: <acMKUXmN7BFDjfGu@desktop0a>
On 3/24/26 16:04, Roberto Ricci wrote:
> On 2026-03-24 14:00 -0600, Shuah Khan wrote:
>> On 3/23/26 19:35, Roberto Ricci wrote:
>>> Remove useless spaces at the end of some lines in
>>> cpupower-frequency-info.1.
>>
>> Why are the spaces useless and what happens if you don't
>> remove them?
>
> They seem to be both useless and harmless. With or without trailing
> spaces, the output is identical (tested with both mandoc and groff).
> Since I added the new options by copy-pasting the existing ones and
> changing the text, my patch added lines with trailing whitespace and
> checkpatch.pl complained about this. Removing these spaces from just the
> new lines fixes the error, but I decided to remove them from all the
> lines in the file for consistency.
Right - I ran these through mandoc - Since they don't change anything,
I would rather not take these whitespace removal patches.
Is there a dependency between the whitespace ones and the other patches?
Can you drop the whitespace ones and send me just the fix patches?
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH v4 1/6] cpupower-frequency-set.1: trim trailing whitespace
From: Roberto Ricci @ 2026-03-24 22:08 UTC (permalink / raw)
To: Shuah Khan
Cc: Thomas Renninger, John B. Wyatt IV, John Kacur, linux-pm,
linux-kernel
In-Reply-To: <1c76b560-c40f-4069-b056-c4addc33f470@linuxfoundation.org>
On 2026-03-24 13:59 -0600, Shuah Khan wrote:
> On 3/23/26 19:35, Roberto Ricci wrote:
> > Remove useless spaces at the end of some lines in cpupower-frequency-set.1.
>
> Why are the spaces useless and what happens if you don't
> remove them?
The trailing spaces seem to be both useless and harmless, since the
output is identical regardless of their presence. I trimmed them from
cpupower-frequency-set.1 for consistency with cpupower-frequency-info.1.
See also my reply to your question about patch 3/6 in this series.
^ permalink raw reply
* Re: [PATCH v4 3/6] cpupower-frequency-info.1: trim trailing whitespace
From: Roberto Ricci @ 2026-03-24 22:04 UTC (permalink / raw)
To: Shuah Khan
Cc: Thomas Renninger, John B. Wyatt IV, John Kacur, linux-pm,
linux-kernel
In-Reply-To: <f229ee71-4297-4fb8-995c-16e86be6e953@linuxfoundation.org>
On 2026-03-24 14:00 -0600, Shuah Khan wrote:
> On 3/23/26 19:35, Roberto Ricci wrote:
> > Remove useless spaces at the end of some lines in
> > cpupower-frequency-info.1.
>
> Why are the spaces useless and what happens if you don't
> remove them?
They seem to be both useless and harmless. With or without trailing
spaces, the output is identical (tested with both mandoc and groff).
Since I added the new options by copy-pasting the existing ones and
changing the text, my patch added lines with trailing whitespace and
checkpatch.pl complained about this. Removing these spaces from just the
new lines fixes the error, but I decided to remove them from all the
lines in the file for consistency.
^ permalink raw reply
* Re: [PATCH v8 8/9] dax/hmem, cxl: Defer and resolve Soft Reserved ownership
From: Koralahalli Channabasappa, Smita @ 2026-03-24 21:50 UTC (permalink / raw)
To: Jonathan Cameron, Smita Koralahalli
Cc: linux-cxl, linux-kernel, nvdimm, linux-fsdevel, linux-pm,
Ard Biesheuvel, Alison Schofield, Vishal Verma, Ira Weiny,
Dan Williams, Yazen Ghannam, Dave Jiang, Davidlohr Bueso,
Matthew Wilcox, Jan Kara, Rafael J . Wysocki, Len Brown,
Pavel Machek, Li Ming, Jeff Johnson, Ying Huang, Yao Xingtao,
Peter Zijlstra, Greg Kroah-Hartman, Nathan Fontenot, Terry Bowman,
Robert Richter, Benjamin Cheatham, Zhijian Li, Borislav Petkov,
Tomasz Wolski
In-Reply-To: <20260323181331.000018f2@huawei.com>
Hi Jonathan,
On 3/23/2026 11:13 AM, Jonathan Cameron wrote:
> On Sun, 22 Mar 2026 19:53:41 +0000
> Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com> wrote:
>
>> The current probe time ownership check for Soft Reserved memory based
>> solely on CXL window intersection is insufficient. dax_hmem probing is not
>> always guaranteed to run after CXL enumeration and region assembly, which
>> can lead to incorrect ownership decisions before the CXL stack has
>> finished publishing windows and assembling committed regions.
>>
>> Introduce deferred ownership handling for Soft Reserved ranges that
>> intersect CXL windows. When such a range is encountered during the
>> initial dax_hmem probe, schedule deferred work to wait for the CXL stack
>> to complete enumeration and region assembly before deciding ownership.
>>
>> Once the deferred work runs, evaluate each Soft Reserved range
>> individually: if a CXL region fully contains the range, skip it and let
>> dax_cxl bind. Otherwise, register it with dax_hmem. This per-range
>> ownership model avoids the need for CXL region teardown and
>> alloc_dax_region() resource exclusion prevents double claiming.
>>
>> Introduce a boolean flag dax_hmem_initial_probe to live inside device.c
>> so it survives module reload. Ensure dax_cxl defers driver registration
>> until dax_hmem has completed ownership resolution. dax_cxl calls
>> dax_hmem_flush_work() before cxl_driver_register(), which both waits for
>> the deferred work to complete and creates a module symbol dependency that
>> forces dax_hmem.ko to load before dax_cxl.
>>
>> Co-developed-by: Dan Williams <dan.j.williams@intel.com>
>> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>> Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
>
> https://sashiko.dev/#/patchset/20260322195343.206900-1-Smita.KoralahalliChannabasappa%40amd.com
> Might be worth a look. I think the last comment is potentially correct
> though unlikely a platform_driver_register() actually fails.
>
> I've not looked too closely at the others. Given this was doing something
> unusual I thought I'd see what it found. Looks like some interesting
> questions if nothing else.
Thanks for pointing this out. I went through the findings:
The init error path one is valid I think, if
platform_driver_register(&dax_hmem_driver) fails after
dax_hmem_platform_driver has already probed and queued work, the error
path doesn't flush the work or release the pdev reference.
I was thinking something like below for v9:
@@ -258,8 +262,13 @@ static __init int dax_hmem_init(void)
return rc;
rc = platform_driver_register(&dax_hmem_driver);
- if (rc)
+ if (rc) {
+ if (dax_hmem_work.pdev) {
+ flush_work(&dax_hmem_work.work);
+ put_device(&dax_hmem_work.pdev->dev);
+ }
platform_driver_unregister(&dax_hmem_platform_driver);
+ }
return rc;
}
Worth adding considering the unlikeliness?
The others I looked at the IS_ENABLED vs IS_REACHABLE question is
something I'm discussing with Dan in 3/9 (there's a Kconfig dependency
and CXL_BUS dependency fix needed I guess), the module reload behavior
is intentional and others are mostly false positives I think..
Thanks,
Smita
>
>> ---
>> drivers/dax/bus.h | 7 ++++
>> drivers/dax/cxl.c | 1 +
>> drivers/dax/hmem/device.c | 3 ++
>> drivers/dax/hmem/hmem.c | 74 +++++++++++++++++++++++++++++++++++++++
>> 4 files changed, 85 insertions(+)
>>
>> diff --git a/drivers/dax/bus.h b/drivers/dax/bus.h
>> index cbbf64443098..ebbfe2d6da14 100644
>> --- a/drivers/dax/bus.h
>> +++ b/drivers/dax/bus.h
>> @@ -49,6 +49,13 @@ void dax_driver_unregister(struct dax_device_driver *dax_drv);
>> void kill_dev_dax(struct dev_dax *dev_dax);
>> bool static_dev_dax(struct dev_dax *dev_dax);
>>
>> +#if IS_ENABLED(CONFIG_DEV_DAX_HMEM)
>> +extern bool dax_hmem_initial_probe;
>> +void dax_hmem_flush_work(void);
>> +#else
>> +static inline void dax_hmem_flush_work(void) { }
>> +#endif
>> +
>> #define MODULE_ALIAS_DAX_DEVICE(type) \
>> MODULE_ALIAS("dax:t" __stringify(type) "*")
>> #define DAX_DEVICE_MODALIAS_FMT "dax:t%d"
>> diff --git a/drivers/dax/cxl.c b/drivers/dax/cxl.c
>> index a2136adfa186..3ab39b77843d 100644
>> --- a/drivers/dax/cxl.c
>> +++ b/drivers/dax/cxl.c
>> @@ -44,6 +44,7 @@ static struct cxl_driver cxl_dax_region_driver = {
>>
>> static void cxl_dax_region_driver_register(struct work_struct *work)
>> {
>> + dax_hmem_flush_work();
>> cxl_driver_register(&cxl_dax_region_driver);
>> }
>>
>> diff --git a/drivers/dax/hmem/device.c b/drivers/dax/hmem/device.c
>> index 56e3cbd181b5..991a4bf7d969 100644
>> --- a/drivers/dax/hmem/device.c
>> +++ b/drivers/dax/hmem/device.c
>> @@ -8,6 +8,9 @@
>> static bool nohmem;
>> module_param_named(disable, nohmem, bool, 0444);
>>
>> +bool dax_hmem_initial_probe;
>> +EXPORT_SYMBOL_GPL(dax_hmem_initial_probe);
>> +
>> static bool platform_initialized;
>> static DEFINE_MUTEX(hmem_resource_lock);
>> static struct resource hmem_active = {
>> diff --git a/drivers/dax/hmem/hmem.c b/drivers/dax/hmem/hmem.c
>> index ca752db03201..9ceda6b5cadf 100644
>> --- a/drivers/dax/hmem/hmem.c
>> +++ b/drivers/dax/hmem/hmem.c
>> @@ -3,6 +3,7 @@
>> #include <linux/memregion.h>
>> #include <linux/module.h>
>> #include <linux/dax.h>
>> +#include <cxl/cxl.h>
>> #include "../bus.h"
>>
>> static bool region_idle;
>> @@ -58,6 +59,23 @@ static void release_hmem(void *pdev)
>> platform_device_unregister(pdev);
>> }
>>
>> +struct dax_defer_work {
>> + struct platform_device *pdev;
>> + struct work_struct work;
>> +};
>> +
>> +static void process_defer_work(struct work_struct *w);
>> +
>> +static struct dax_defer_work dax_hmem_work = {
>> + .work = __WORK_INITIALIZER(dax_hmem_work.work, process_defer_work),
>> +};
>> +
>> +void dax_hmem_flush_work(void)
>> +{
>> + flush_work(&dax_hmem_work.work);
>> +}
>> +EXPORT_SYMBOL_GPL(dax_hmem_flush_work);
>> +
>> static int __hmem_register_device(struct device *host, int target_nid,
>> const struct resource *res)
>> {
>> @@ -122,6 +140,11 @@ static int hmem_register_device(struct device *host, int target_nid,
>> if (IS_ENABLED(CONFIG_DEV_DAX_CXL) &&
>> region_intersects(res->start, resource_size(res), IORESOURCE_MEM,
>> IORES_DESC_CXL) != REGION_DISJOINT) {
>> + if (!dax_hmem_initial_probe) {
>> + dev_dbg(host, "await CXL initial probe: %pr\n", res);
>> + queue_work(system_long_wq, &dax_hmem_work.work);
>> + return 0;
>> + }
>> dev_dbg(host, "deferring range to CXL: %pr\n", res);
>> return 0;
>> }
>> @@ -129,8 +152,54 @@ static int hmem_register_device(struct device *host, int target_nid,
>> return __hmem_register_device(host, target_nid, res);
>> }
>>
>> +static int hmem_register_cxl_device(struct device *host, int target_nid,
>> + const struct resource *res)
>> +{
>> + if (region_intersects(res->start, resource_size(res), IORESOURCE_MEM,
>> + IORES_DESC_CXL) == REGION_DISJOINT)
>> + return 0;
>> +
>> + if (cxl_region_contains_resource((struct resource *)res)) {
>> + dev_dbg(host, "CXL claims resource, dropping: %pr\n", res);
>> + return 0;
>> + }
>> +
>> + dev_dbg(host, "CXL did not claim resource, registering: %pr\n", res);
>> + return __hmem_register_device(host, target_nid, res);
>> +}
>> +
>> +static void process_defer_work(struct work_struct *w)
>> +{
>> + struct dax_defer_work *work = container_of(w, typeof(*work), work);
>> + struct platform_device *pdev;
>> +
>> + if (!work->pdev)
>> + return;
>> +
>> + pdev = work->pdev;
>> +
>> + /* Relies on cxl_acpi and cxl_pci having had a chance to load */
>> + wait_for_device_probe();
>> +
>> + guard(device)(&pdev->dev);
>> + if (!pdev->dev.driver)
>> + return;
>> +
>> + if (!dax_hmem_initial_probe) {
>> + dax_hmem_initial_probe = true;
>> + walk_hmem_resources(&pdev->dev, hmem_register_cxl_device);
>> + }
>> +}
>> +
>> static int dax_hmem_platform_probe(struct platform_device *pdev)
>> {
>> + if (work_pending(&dax_hmem_work.work))
>> + return -EBUSY;
>> +
>> + if (!dax_hmem_work.pdev)
>> + dax_hmem_work.pdev =
>> + to_platform_device(get_device(&pdev->dev));
>> +
>> return walk_hmem_resources(&pdev->dev, hmem_register_device);
>> }
>>
>> @@ -168,6 +237,11 @@ static __init int dax_hmem_init(void)
>>
>> static __exit void dax_hmem_exit(void)
>> {
>> + if (dax_hmem_work.pdev) {
>> + flush_work(&dax_hmem_work.work);
>> + put_device(&dax_hmem_work.pdev->dev);
>> + }
>> +
>> platform_driver_unregister(&dax_hmem_driver);
>> platform_driver_unregister(&dax_hmem_platform_driver);
>> }
>
^ permalink raw reply
* Re: [PATCH v3 06/12] amd-pstate: Add sysfs support for floor_freq and floor_count
From: Mario Limonciello @ 2026-03-24 21:39 UTC (permalink / raw)
To: Gautham R. Shenoy, Rafael J . Wysocki, Viresh Kumar,
K Prateek Nayak
Cc: linux-kernel, linux-pm
In-Reply-To: <20260320144321.18543-7-gautham.shenoy@amd.com>
On 3/20/26 09:43, Gautham R. Shenoy wrote:
> When Floor Performance feature is supported by the platform, expose
> two sysfs files:
>
> * amd_pstate_floor_freq to allow userspace to request the floor
> frequency for each CPU.
>
> * amd_pstate_floor_count which advertises the number of distinct
> levels of floor frequencies supported on this platform.
>
> Reset the floor_perf to bios_floor_perf in the suspend, offline, and
> exit paths, and restore the value to the cached user-request
> floor_freq on the resume and online paths mirroring how bios_min_perf
> is handled for MSR_AMD_CPPC_REQ.
>
> Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
> ---
> drivers/cpufreq/amd-pstate.c | 93 +++++++++++++++++++++++++++++++++---
> drivers/cpufreq/amd-pstate.h | 2 +
> 2 files changed, 89 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
> index 53b8173ff183..a068c4457a8f 100644
> --- a/drivers/cpufreq/amd-pstate.c
> +++ b/drivers/cpufreq/amd-pstate.c
> @@ -383,8 +383,10 @@ static int amd_pstate_init_floor_perf(struct cpufreq_policy *policy)
> return ret;
> }
>
> - cpudata->bios_floor_perf = floor_perf;
>
> + cpudata->bios_floor_perf = floor_perf;
Double check the whitespace between 5 and 6; I wouldn't expect this line
to ping pong.
> + cpudata->floor_freq = perf_to_freq(cpudata->perf, cpudata->nominal_freq,
> + floor_perf);
> return 0;
> }
>
> @@ -1288,6 +1290,46 @@ static ssize_t show_energy_performance_preference(
> return sysfs_emit(buf, "%s\n", energy_perf_strings[preference]);
> }
>
> +static ssize_t store_amd_pstate_floor_freq(struct cpufreq_policy *policy,
> + const char *buf, size_t count)
> +{
> + struct amd_cpudata *cpudata = policy->driver_data;
> + union perf_cached perf = READ_ONCE(cpudata->perf);
> + unsigned int freq;
> + u8 floor_perf;
> + int ret;
> +
> + ret = kstrtouint(buf, 0, &freq);
> + if (ret)
> + return ret;
> +
> + if (freq < policy->cpuinfo.min_freq || freq > policy->max)
> + return -EINVAL;
> +
> + floor_perf = freq_to_perf(perf, cpudata->nominal_freq, freq);
> + ret = amd_pstate_set_floor_perf(policy, floor_perf);
> +
> + if (!ret)
> + cpudata->floor_freq = freq;
> +
> + return ret ?: count;
> +}
> +
> +static ssize_t show_amd_pstate_floor_freq(struct cpufreq_policy *policy, char *buf)
> +{
> + struct amd_cpudata *cpudata = policy->driver_data;
> +
> + return sysfs_emit(buf, "%u\n", cpudata->floor_freq);
> +}
> +
> +static ssize_t show_amd_pstate_floor_count(struct cpufreq_policy *policy, char *buf)
> +{
> + struct amd_cpudata *cpudata = policy->driver_data;
> + u8 count = cpudata->floor_perf_cnt;
> +
> + return sysfs_emit(buf, "%u\n", count);
> +}
> +
> cpufreq_freq_attr_ro(amd_pstate_max_freq);
> cpufreq_freq_attr_ro(amd_pstate_lowest_nonlinear_freq);
>
> @@ -1296,6 +1338,8 @@ cpufreq_freq_attr_ro(amd_pstate_prefcore_ranking);
> cpufreq_freq_attr_ro(amd_pstate_hw_prefcore);
> cpufreq_freq_attr_rw(energy_performance_preference);
> cpufreq_freq_attr_ro(energy_performance_available_preferences);
> +cpufreq_freq_attr_rw(amd_pstate_floor_freq);
> +cpufreq_freq_attr_ro(amd_pstate_floor_count);
>
> struct freq_attr_visibility {
> struct freq_attr *attr;
> @@ -1320,6 +1364,12 @@ static bool epp_visibility(void)
> return cppc_state == AMD_PSTATE_ACTIVE;
> }
>
> +/* Determines whether amd_pstate_floor_freq related attributes should be visible */
> +static bool floor_freq_visibility(void)
> +{
> + return cpu_feature_enabled(X86_FEATURE_CPPC_PERF_PRIO);
> +}
> +
> static struct freq_attr_visibility amd_pstate_attr_visibility[] = {
> {&amd_pstate_max_freq, always_visible},
> {&amd_pstate_lowest_nonlinear_freq, always_visible},
> @@ -1328,6 +1378,8 @@ static struct freq_attr_visibility amd_pstate_attr_visibility[] = {
> {&amd_pstate_hw_prefcore, prefcore_visibility},
> {&energy_performance_preference, epp_visibility},
> {&energy_performance_available_preferences, epp_visibility},
> + {&amd_pstate_floor_freq, floor_freq_visibility},
> + {&amd_pstate_floor_count, floor_freq_visibility},
> };
>
> static struct freq_attr **get_freq_attrs(void)
> @@ -1748,24 +1800,39 @@ static int amd_pstate_epp_set_policy(struct cpufreq_policy *policy)
>
> static int amd_pstate_cpu_online(struct cpufreq_policy *policy)
> {
> - return amd_pstate_cppc_enable(policy);
> + struct amd_cpudata *cpudata = policy->driver_data;
> + union perf_cached perf = READ_ONCE(cpudata->perf);
> + u8 cached_floor_perf;
> + int ret;
> +
> + ret = amd_pstate_cppc_enable(policy);
> + if (ret)
> + return ret;
> +
> + cached_floor_perf = freq_to_perf(perf, cpudata->nominal_freq, cpudata->floor_freq);
> + return amd_pstate_set_floor_perf(policy, cached_floor_perf);
> }
>
> static int amd_pstate_cpu_offline(struct cpufreq_policy *policy)
> {
> struct amd_cpudata *cpudata = policy->driver_data;
> union perf_cached perf = READ_ONCE(cpudata->perf);
> + int ret;
>
> /*
> * Reset CPPC_REQ MSR to the BIOS value, this will allow us to retain the BIOS specified
> * min_perf value across kexec reboots. If this CPU is just onlined normally after this, the
> * limits, epp and desired perf will get reset to the cached values in cpudata struct
> */
> - return amd_pstate_update_perf(policy, perf.bios_min_perf,
> + ret = amd_pstate_update_perf(policy, perf.bios_min_perf,
> FIELD_GET(AMD_CPPC_DES_PERF_MASK, cpudata->cppc_req_cached),
> FIELD_GET(AMD_CPPC_MAX_PERF_MASK, cpudata->cppc_req_cached),
> FIELD_GET(AMD_CPPC_EPP_PERF_MASK, cpudata->cppc_req_cached),
> false);
> + if (ret)
> + return ret;
> +
> + return amd_pstate_set_floor_perf(policy, cpudata->bios_floor_perf);
> }
>
> static int amd_pstate_suspend(struct cpufreq_policy *policy)
> @@ -1787,6 +1854,10 @@ static int amd_pstate_suspend(struct cpufreq_policy *policy)
> if (ret)
> return ret;
>
> + ret = amd_pstate_set_floor_perf(policy, cpudata->bios_floor_perf);
> + if (ret)
> + return ret;
> +
> /* set this flag to avoid setting core offline*/
> cpudata->suspended = true;
>
> @@ -1798,15 +1869,24 @@ static int amd_pstate_resume(struct cpufreq_policy *policy)
> struct amd_cpudata *cpudata = policy->driver_data;
> union perf_cached perf = READ_ONCE(cpudata->perf);
> int cur_perf = freq_to_perf(perf, cpudata->nominal_freq, policy->cur);
> + u8 cached_floor_perf;
> + int ret;
>
> /* Set CPPC_REQ to last sane value until the governor updates it */
> - return amd_pstate_update_perf(policy, perf.min_limit_perf, cur_perf, perf.max_limit_perf,
> - 0U, false);
> + ret = amd_pstate_update_perf(policy, perf.min_limit_perf, cur_perf, perf.max_limit_perf,
> + 0U, false);
> + if (ret)
> + return ret;
> +
> + cached_floor_perf = freq_to_perf(perf, cpudata->nominal_freq, cpudata->floor_freq);
> + return amd_pstate_set_floor_perf(policy, cached_floor_perf);
> }
>
> static int amd_pstate_epp_resume(struct cpufreq_policy *policy)
> {
> struct amd_cpudata *cpudata = policy->driver_data;
> + union perf_cached perf = READ_ONCE(cpudata->perf);
> + u8 cached_floor_perf;
>
> if (cpudata->suspended) {
> int ret;
> @@ -1819,7 +1899,8 @@ static int amd_pstate_epp_resume(struct cpufreq_policy *policy)
> cpudata->suspended = false;
> }
>
> - return 0;
> + cached_floor_perf = freq_to_perf(perf, cpudata->nominal_freq, cpudata->floor_freq);
> + return amd_pstate_set_floor_perf(policy, cached_floor_perf);
> }
>
> static struct cpufreq_driver amd_pstate_driver = {
> diff --git a/drivers/cpufreq/amd-pstate.h b/drivers/cpufreq/amd-pstate.h
> index f04561da4518..2f7a96836fcd 100644
> --- a/drivers/cpufreq/amd-pstate.h
> +++ b/drivers/cpufreq/amd-pstate.h
> @@ -72,6 +72,7 @@ struct amd_aperf_mperf {
> * @max_limit_freq: Cached value of policy->max (in khz)
> * @nominal_freq: the frequency (in khz) that mapped to nominal_perf
> * @lowest_nonlinear_freq: the frequency (in khz) that mapped to lowest_nonlinear_perf
> + * @floor_freq: Cached value of the user requested floor_freq
> * @cur: Difference of Aperf/Mperf/tsc count between last and current sample
> * @prev: Last Aperf/Mperf/tsc count value read from register
> * @freq: current cpu frequency value (in khz)
> @@ -101,6 +102,7 @@ struct amd_cpudata {
> u32 max_limit_freq;
> u32 nominal_freq;
> u32 lowest_nonlinear_freq;
> + u32 floor_freq;
>
> struct amd_aperf_mperf cur;
> struct amd_aperf_mperf prev;
^ permalink raw reply
* Re: [PATCH v3 05/12] amd-pstate: Add support for CPPC_REQ2 and FLOOR_PERF
From: Mario Limonciello @ 2026-03-24 21:38 UTC (permalink / raw)
To: Gautham R. Shenoy, Rafael J . Wysocki, Viresh Kumar,
K Prateek Nayak
Cc: linux-kernel, linux-pm
In-Reply-To: <20260320144321.18543-6-gautham.shenoy@amd.com>
On 3/20/26 09:43, Gautham R. Shenoy wrote:
> Some future AMD processors have feature named "CPPC Performance
> Priority" which lets userspace specify different floor performance
> levels for different CPUs. The platform firmware takes these different
> floor performance levels into consideration while throttling the CPUs
> under power/thermal constraints. The presence of this feature is
> indicated by bit 16 of the EDX register for CPUID leaf
> 0x80000007. More details can be found in AMD Publication titled "AMD64
> Collaborative Processor Performance Control (CPPC) Performance
> Priority" Revision 1.10.
>
> The number of distinct floor performance levels supported on the
> platform will be advertised through the bits 32:39 of the
> MSR_AMD_CPPC_CAP1. Bits 0:7 of a new MSR MSR_AMD_CPPC_REQ2
> (0xc00102b5) will be used to specify the desired floor performance
> level for that CPU.
>
> Add support for the aforementioned MSR_AMD_CPPC_REQ2, and macros for
> parsing and updating the relevant bits from MSR_AMD_CPPC_CAP1 and
> MSR_AMD_CPPC_REQ2.
>
> On boot if the default value of the MSR_AMD_CPPC_REQ2[7:0] (Floor
> Perf) is lower than CPPC.lowest_perf, and thus invalid, initialize it
> to MSR_AMD_CPPC_CAP1.nominal_perf which is a sane default value.
>
> Save the boot-time floor_perf during amd_pstate_init_floor_perf(). In
> a subsequent patch it will be restored in the suspend, offline, and
> exit paths, mirroring how bios_min_perf is handled for
> MSR_AMD_CPPC_REQ.
>
> Link: https://docs.amd.com/v/u/en-US/69206_1.10_AMD64_CPPC_PUB
> Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
> ---
> arch/x86/include/asm/msr-index.h | 5 ++
> drivers/cpufreq/amd-pstate.c | 78 +++++++++++++++++++++++++++++++-
> drivers/cpufreq/amd-pstate.h | 6 +++
> 3 files changed, 88 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
> index 6673601246b3..e126c7fb69cf 100644
> --- a/arch/x86/include/asm/msr-index.h
> +++ b/arch/x86/include/asm/msr-index.h
> @@ -765,12 +765,14 @@
> #define MSR_AMD_CPPC_CAP2 0xc00102b2
> #define MSR_AMD_CPPC_REQ 0xc00102b3
> #define MSR_AMD_CPPC_STATUS 0xc00102b4
> +#define MSR_AMD_CPPC_REQ2 0xc00102b5
>
> /* Masks for use with MSR_AMD_CPPC_CAP1 */
> #define AMD_CPPC_LOWEST_PERF_MASK GENMASK(7, 0)
> #define AMD_CPPC_LOWNONLIN_PERF_MASK GENMASK(15, 8)
> #define AMD_CPPC_NOMINAL_PERF_MASK GENMASK(23, 16)
> #define AMD_CPPC_HIGHEST_PERF_MASK GENMASK(31, 24)
> +#define AMD_CPPC_FLOOR_PERF_CNT_MASK GENMASK_ULL(39, 32)
>
> /* Masks for use with MSR_AMD_CPPC_REQ */
> #define AMD_CPPC_MAX_PERF_MASK GENMASK(7, 0)
> @@ -778,6 +780,9 @@
> #define AMD_CPPC_DES_PERF_MASK GENMASK(23, 16)
> #define AMD_CPPC_EPP_PERF_MASK GENMASK(31, 24)
>
> +/* Masks for use with MSR_AMD_CPPC_REQ2 */
> +#define AMD_CPPC_FLOOR_PERF_MASK GENMASK(7, 0)
> +
> /* AMD Performance Counter Global Status and Control MSRs */
> #define MSR_AMD64_PERF_CNTR_GLOBAL_STATUS 0xc0000300
> #define MSR_AMD64_PERF_CNTR_GLOBAL_CTL 0xc0000301
> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
> index 4de2037a414c..53b8173ff183 100644
> --- a/drivers/cpufreq/amd-pstate.c
> +++ b/drivers/cpufreq/amd-pstate.c
> @@ -329,6 +329,65 @@ static inline int amd_pstate_set_epp(struct cpufreq_policy *policy, u8 epp)
> return static_call(amd_pstate_set_epp)(policy, epp);
> }
>
> +static int amd_pstate_set_floor_perf(struct cpufreq_policy *policy, u8 perf)
> +{
> + struct amd_cpudata *cpudata = policy->driver_data;
> + u64 value, prev;
> + int ret;
> +
> + if (!cpu_feature_enabled(X86_FEATURE_CPPC_PERF_PRIO))
> + return 0;
> +
> + value = prev = READ_ONCE(cpudata->cppc_req2_cached);
> + FIELD_MODIFY(AMD_CPPC_FLOOR_PERF_MASK, &value, perf);
> +
> + if (value == prev)
> + return 0;
> +
> + ret = wrmsrq_on_cpu(cpudata->cpu, MSR_AMD_CPPC_REQ2, value);
> + if (ret) {
> + pr_err("failed to set CPPC REQ2 value. Error (%d)\n", ret);
> + return ret;
> + }
> +
> + WRITE_ONCE(cpudata->cppc_req2_cached, value);
> +
> + return ret;
> +}
> +
> +static int amd_pstate_init_floor_perf(struct cpufreq_policy *policy)
> +{
> + struct amd_cpudata *cpudata = policy->driver_data;
> + u8 floor_perf;
> + u64 value;
> + int ret;
> +
> + if (!cpu_feature_enabled(X86_FEATURE_CPPC_PERF_PRIO))
> + return 0;
> +
> + ret = rdmsrq_on_cpu(cpudata->cpu, MSR_AMD_CPPC_REQ2, &value);
> + if (ret) {
> + pr_err("failed to read CPPC REQ2 value. Error (%d)\n", ret);
> + return ret;
> + }
> +
> + WRITE_ONCE(cpudata->cppc_req2_cached, value);
> + floor_perf = FIELD_GET(AMD_CPPC_FLOOR_PERF_MASK,
> + cpudata->cppc_req2_cached);
> +
> + /* Set a sane value for floor_perf if the default value is invalid */
> + if (floor_perf < cpudata->perf.lowest_perf) {
> + floor_perf = cpudata->perf.nominal_perf;
> + ret = amd_pstate_set_floor_perf(policy, floor_perf);
> + if (ret)
> + return ret;
> + }
> +
> + cpudata->bios_floor_perf = floor_perf;
> +
> + return 0;
> +}
> +
> static int shmem_set_epp(struct cpufreq_policy *policy, u8 epp)
> {
> struct amd_cpudata *cpudata = policy->driver_data;
> @@ -426,6 +485,7 @@ static int msr_init_perf(struct amd_cpudata *cpudata)
> perf.lowest_perf = FIELD_GET(AMD_CPPC_LOWEST_PERF_MASK, cap1);
> WRITE_ONCE(cpudata->perf, perf);
> WRITE_ONCE(cpudata->prefcore_ranking, FIELD_GET(AMD_CPPC_HIGHEST_PERF_MASK, cap1));
> + WRITE_ONCE(cpudata->floor_perf_cnt, FIELD_GET(AMD_CPPC_FLOOR_PERF_CNT_MASK, cap1));
>
> return 0;
> }
> @@ -1024,6 +1084,7 @@ static int amd_pstate_cpu_init(struct cpufreq_policy *policy)
> cpudata->nominal_freq,
> perf.highest_perf);
>
> + policy->driver_data = cpudata;
> ret = amd_pstate_cppc_enable(policy);
> if (ret)
> goto free_cpudata1;
> @@ -1036,6 +1097,12 @@ static int amd_pstate_cpu_init(struct cpufreq_policy *policy)
> if (cpu_feature_enabled(X86_FEATURE_CPPC))
> policy->fast_switch_possible = true;
>
> + ret = amd_pstate_init_floor_perf(policy);
> + if (ret) {
> + dev_err(dev, "Failed to initialize Floor Perf (%d)\n", ret);
> + goto free_cpudata1;
> + }
> +
> ret = freq_qos_add_request(&policy->constraints, &cpudata->req[0],
> FREQ_QOS_MIN, FREQ_QOS_MIN_DEFAULT_VALUE);
> if (ret < 0) {
> @@ -1050,7 +1117,6 @@ static int amd_pstate_cpu_init(struct cpufreq_policy *policy)
> goto free_cpudata2;
> }
>
> - policy->driver_data = cpudata;
>
> if (!current_pstate_driver->adjust_perf)
> current_pstate_driver->adjust_perf = amd_pstate_adjust_perf;
> @@ -1062,6 +1128,7 @@ static int amd_pstate_cpu_init(struct cpufreq_policy *policy)
> free_cpudata1:
> pr_warn("Failed to initialize CPU %d: %d\n", policy->cpu, ret);
> kfree(cpudata);
> + policy->driver_data = NULL;
> return ret;
> }
>
> @@ -1072,6 +1139,7 @@ static void amd_pstate_cpu_exit(struct cpufreq_policy *policy)
>
> /* Reset CPPC_REQ MSR to the BIOS value */
> amd_pstate_update_perf(policy, perf.bios_min_perf, 0U, 0U, 0U, false);
> + amd_pstate_set_floor_perf(policy, cpudata->bios_floor_perf);
>
> freq_qos_remove_request(&cpudata->req[1]);
> freq_qos_remove_request(&cpudata->req[0]);
> @@ -1598,6 +1666,12 @@ static int amd_pstate_epp_cpu_init(struct cpufreq_policy *policy)
> if (ret)
> goto free_cpudata1;
>
> + ret = amd_pstate_init_floor_perf(policy);
> + if (ret) {
> + dev_err(dev, "Failed to initialize Floor Perf (%d)\n", ret);
> + goto free_cpudata1;
> + }
> +
> current_pstate_driver->adjust_perf = NULL;
>
> return 0;
> @@ -1605,6 +1679,7 @@ static int amd_pstate_epp_cpu_init(struct cpufreq_policy *policy)
> free_cpudata1:
> pr_warn("Failed to initialize CPU %d: %d\n", policy->cpu, ret);
> kfree(cpudata);
> + policy->driver_data = NULL;
> return ret;
> }
>
> @@ -1617,6 +1692,7 @@ static void amd_pstate_epp_cpu_exit(struct cpufreq_policy *policy)
>
> /* Reset CPPC_REQ MSR to the BIOS value */
> amd_pstate_update_perf(policy, perf.bios_min_perf, 0U, 0U, 0U, false);
> + amd_pstate_set_floor_perf(policy, cpudata->bios_floor_perf);
>
> kfree(cpudata);
> policy->driver_data = NULL;
> diff --git a/drivers/cpufreq/amd-pstate.h b/drivers/cpufreq/amd-pstate.h
> index cb45fdca27a6..f04561da4518 100644
> --- a/drivers/cpufreq/amd-pstate.h
> +++ b/drivers/cpufreq/amd-pstate.h
> @@ -62,9 +62,12 @@ struct amd_aperf_mperf {
> * @cpu: CPU number
> * @req: constraint request to apply
> * @cppc_req_cached: cached performance request hints
> + * @cppc_req2_cached: cached value of MSR_AMD_CPPC_REQ2
> * @perf: cached performance-related data
> * @prefcore_ranking: the preferred core ranking, the higher value indicates a higher
> * priority.
> + * @floor_perf_cnt: Cached value of the number of distinct floor
> + * performance levels supported
> * @min_limit_freq: Cached value of policy->min (in khz)
> * @max_limit_freq: Cached value of policy->max (in khz)
> * @nominal_freq: the frequency (in khz) that mapped to nominal_perf
> @@ -87,10 +90,13 @@ struct amd_cpudata {
>
> struct freq_qos_request req[2];
> u64 cppc_req_cached;
> + u64 cppc_req2_cached;
>
> union perf_cached perf;
>
> u8 prefcore_ranking;
> + u8 floor_perf_cnt;
> + u8 bios_floor_perf;
It looks like you forgot to update doc for bios_floor_perf
> u32 min_limit_freq;
> u32 max_limit_freq;
> u32 nominal_freq;
^ permalink raw reply
* Re: [PATCH v4 3/6] cpupower-frequency-info.1: trim trailing whitespace
From: Shuah Khan @ 2026-03-24 20:00 UTC (permalink / raw)
To: Roberto Ricci, Thomas Renninger, Shuah Khan, John B. Wyatt IV,
John Kacur, linux-pm, linux-kernel, Shuah Khan
In-Reply-To: <20260324013543.4776-4-io@r-ricci.it>
On 3/23/26 19:35, Roberto Ricci wrote:
> Remove useless spaces at the end of some lines in
> cpupower-frequency-info.1.
>
Why are the spaces useless and what happens if you don't
remove them?
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH v4 1/6] cpupower-frequency-set.1: trim trailing whitespace
From: Shuah Khan @ 2026-03-24 19:59 UTC (permalink / raw)
To: Roberto Ricci, Thomas Renninger, Shuah Khan, John B. Wyatt IV,
John Kacur, linux-pm, linux-kernel, Shuah Khan
In-Reply-To: <20260324013543.4776-2-io@r-ricci.it>
On 3/23/26 19:35, Roberto Ricci wrote:
> Remove useless spaces at the end of some lines in cpupower-frequency-set.1.
Why are the spaces useless and what happens if you don't
remove them?
>
> Signed-off-by: Roberto Ricci <io@r-ricci.it>
> ---
> .../cpupower/man/cpupower-frequency-set.1 | 42 +++++++++----------
> 1 file changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/tools/power/cpupower/man/cpupower-frequency-set.1 b/tools/power/cpupower/man/cpupower-frequency-set.1
> index b50570221a5b..fded317c8c51 100644
> --- a/tools/power/cpupower/man/cpupower-frequency-set.1
> +++ b/tools/power/cpupower/man/cpupower-frequency-set.1
> @@ -1,52 +1,52 @@
> .TH "CPUPOWER\-FREQUENCY\-SET" "1" "0.1" "" "cpupower Manual"
> .SH "NAME"
> -.LP
> +.LP
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH v6 3/9] cxl/region: Skip decoder reset on detach for autodiscovered regions
From: Dan Williams @ 2026-03-24 19:46 UTC (permalink / raw)
To: Alison Schofield, Dan Williams
Cc: Smita Koralahalli, linux-cxl, linux-kernel, nvdimm, linux-fsdevel,
linux-pm, Ard Biesheuvel, Vishal Verma, Ira Weiny,
Jonathan Cameron, Yazen Ghannam, Dave Jiang, Davidlohr Bueso,
Matthew Wilcox, Jan Kara, Rafael J . Wysocki, Len Brown,
Pavel Machek, Li Ming, Jeff Johnson, Ying Huang, Yao Xingtao,
Peter Zijlstra, Greg Kroah-Hartman, Nathan Fontenot, Terry Bowman,
Robert Richter, Benjamin Cheatham, Zhijian Li, Borislav Petkov,
Tomasz Wolski
In-Reply-To: <absY10LzUqb3vK7A@aschofie-mobl2.lan>
Alison Schofield wrote:
> On Wed, Mar 11, 2026 at 02:37:46PM -0700, Dan Williams wrote:
> > Smita Koralahalli wrote:
> > > __cxl_decoder_detach() currently resets decoder programming whenever a
> > > region is detached if cxl_config_state is beyond CXL_CONFIG_ACTIVE. For
> > > autodiscovered regions, this can incorrectly tear down decoder state
> > > that may be relied upon by other consumers or by subsequent ownership
> > > decisions.
> > >
> > > Skip cxl_region_decode_reset() during detach when CXL_REGION_F_AUTO is
> > > set.
> > >
> > > Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
> > > Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> > > Reviewed-by: Dave Jiang <dave.jiang@intel.com>
> > > Reviewed-by: Alejandro Lucero <alucerop@amd.com>
> > > ---
> > > drivers/cxl/core/region.c | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c
> > > index ae899f68551f..45ee598daf95 100644
> > > --- a/drivers/cxl/core/region.c
> > > +++ b/drivers/cxl/core/region.c
> > > @@ -2178,7 +2178,9 @@ __cxl_decoder_detach(struct cxl_region *cxlr,
> > > cxled->part = -1;
> > >
> > > if (p->state > CXL_CONFIG_ACTIVE) {
> > > - cxl_region_decode_reset(cxlr, p->interleave_ways);
> > > + if (!test_bit(CXL_REGION_F_AUTO, &cxlr->flags))
> > > + cxl_region_decode_reset(cxlr, p->interleave_ways);
> > > +
> > > p->state = CXL_CONFIG_ACTIVE;
> >
>
> Hi Dan,
>
> > tl;dr: I do not think we need this, I do think we need to clarify to
> > users what enable/disable and/or hot remove violence is handled and not
> > handled by the CXL core.
>
> I'm chiming in here because although this patch is no longer needed for
> this series, it has become a dependency for the Type 2 series.
Like I replied to Alejandro it is not a dependency for the type-2 series
[1]. It *is* a fix for the issue reported by PJ, but it can go in
independent of the base type-2 work as a standalone capability.
[1]: http://lore.kernel.org/69b8b9181bafd_452b100cb@dwillia2-mobl4.notmuch
> So this
> follow-up focuses on the hot-remove, endpoint-detach case where
> preserving decoders across detach is still needed for later recovery.
>
> Some inline responses to you, and then a diff is appended for a
> direction check.
>
> > So this looks deceptively simple, but I think it is incomplete or at
> > least adds to the current confusion. A couple points to consider:
> >
> > 1/ There is no corresponding clear_bit(CXL_REGION_F_AUTO, ...) anywhere in
> > the driver. Yes, admin can still force cxl_region_decode_reset() via
> > commit_store() path, but admin can not force
> > cxl_region_teardown_targets() in the __cxl_decoder_detach() path. I do
> > not like that this causes us to end up with 2 separate considerations
> > for when __cxl_decoder_detach() skips cleanup actions
> > (cxl_region_teardown_targets() and cxl_region_decode_reset()). See
> > below, I think the cxl_region_teardown_targets() check is probably
> > bogus.
>
> Rather than repurposing CXL_REGION_F_AUTO, this splits decode-reset policy
> from AUTO. A new region-scoped CXL_REGION_F_PRESERVE_DECODE flag is introduced
> and cleared on explicit decommit in commit_store(). AUTO remains origin/assembly
> state.
Just like the decoder LOCK bit the preservation setting is a decoder
property, not a region property. Region auto-assembly is then just an
automatic way to set that decoder policy.
So, no, I would not expect a new region flag for this policy.
> This does still leave two cleanup decisions:
> 1) decode reset (now keyed off PRESERVE_DECODE)
> 2) target teardown (still using existing AUTO behavior)
>
> No change to cxl_region_teardown_targets() in this step.
Turns out that cxl_region_teardown_targets() never needed to consider
the CXL_F_REGION_AUTO flag.
> > At a minimum I think commit_store() should clear CXL_REGION_F_AUTO on
> > decommit such that cleaning up decoders and targets later proceeds as
> > expected.
>
> This point is addressed by clearing CXL_REGION_F_PRESERVE_DECODE instead.
> Explicit decommit is treated as destructive and disables decode preservation
> before unbind/reset.
>
> >
> > 2/ The hard part about CXL region cleanup is that it needs to be prepared
> > for:
> >
> > a/ user manually removes the region via sysfs
> >
> > b/ user manually disables cxl_port, cxl_mem, or cxl_acpi causing the
> > endpoint port to be removed
> >
> > c/ user physically removes the memdev causing the endpoint port to be
> > removed (CXL core can not tell the difference with 2b/ it just sees
> > cxl_mem_driver::remove() operation invocation)
> >
> > d/ setup action fails and region setup is unwound
>
> Agreed. This change targets 2b, 2c.
>
> >
> > The cxl_region_decode_reset() is in __cxl_decoder_detach() because of
> > 2b/ and 2c/. No other chance to cleanup the decode topology once the
> > endpoint decoders are on their way out of the system.
>
> Agreed. The reset remains. Proposed change only makes it conditional on
> explicit region policy rather than AUTO.
>
> >
> > In this case though the patch was generated back when we were committed
> > to cleaning up failed to assemble regions, a new 2d/ case, right?
> > However, in that case the decoder is not leaving the system. The
> > questions that arrive from that analysis are:
> >
> > * Is this patch still needed now that there is no auto-cleanup?
>
> Not for this Soft Reserved series, but yes for Type2 hotplug.
Type-2 hotplug is not the issue, it is boot-time configuration
preservation over device reset which is a different challenge.
> > * If this patch is still needed is it better to skip
> > cxl_region_decode_reset() based on the 'enum cxl_detach_mode' rather
> > than the CXL_REGION_F_AUTO flag? I.e. skip reset in the 2d/ case, or
> > some other new general flag that says "please preserve hardware
> > configuration".
>
> I looked at using and expanding the cxl_detach_mode enum and rejected as
> not the right scope. The current detach mode is attached to an individual
> detach operation, whereas preserve vs reset decision applies to the region
> decode topology as a whole. If we expand detach mode for this region
> wide policy, then may risk inconsistent handling across endpoint of the
> same region. Just seemed wrong place. I could be missing another reason
> why you looked at it.
Regions are an emergent property from decoder settings. Decoder settings
come from firmware, user actions, and with the type-2 series driver
actions. Firmware, user and driver actions are per-decoder especially
because the behavior needed here is similar to the decoder LOCK bit.
Region assembly can set a default decoder policy, but the management of
that decoder policy need not go through the region.
Either way, settling this question can be post type-2 base series event,
not a lead-in dependency.
[..]
> > It is helpful that violence has been the default so far. So it allows to
> > introduce a decoder shutdown policy toggle where CXL_REGION_F_AUTO flags
> > decoders as "preserve" by default. Region decommit clears that flag,
> > and/or userspace can toggle that per endpoint decoder flag to determine
> > what happens when decoders leave the system. That probably also wants
> > some lockdown interaction such that root can not force unplug memory by
> > unbinding a driver.
>
> As a step in the direction you suggest, AND aiming to address Type2
> need, here is what I'd like a direction check on:
>
> Start separating decode-reset policy rom CXL_REGION_F_AUTO:
> - keep CXL_REGION_F_AUTO as origin / assembly semantics
> - introduce CXL_REGION_F_PRESERVE_DECODE as a region-scoped policy
Not yet convinced about this.
> - initialize that policy from auto-assembly
> - clear it on explicit decommit in commit_store()
My expectation is still clear it on decoder configuration change, add an
attribute to toggle it independent of changing the decoder
configuration.
> - use it to gate cxl_region_decode_reset() in __cxl_decoder_detach()
cxl_region_decode_reset() just automates asking each decoder to carry
out reset if the decoder policy allows.
> The decode-reset decision is factored through a small helper,
> cxl_region_preserve_decode(), so the policy can be extended independent
> of the detach mechanics. Maybe overkill in this simple case, but I
> wanted to acknowledge the 'policy' direction.
Appreciate you pulling this together. I want to land type-2 with the
existing expectation that unload is always destructive then circle back
to address this additional detail because it is more than just decoder
policy that needs to be managed. The type-2 driver may need help finding
its platform firmware configured address range if a device reset
destroyed the decoder settings.
^ permalink raw reply
* Re: [PATCH 5/5] fpga: m10bmc-sec: switch show_canceled_csk() to using sysfs_emit()
From: Yury Norov @ 2026-03-24 18:38 UTC (permalink / raw)
To: Xu Yilun
Cc: linux-kernel, Christophe Leroy (CS GROUP), Peter Zijlstra (Intel),
Rafael J. Wysocki, Alexander Shishkin, Daniel Lezcano,
Ingo Molnar, James Clark, Kees Cook, Lukasz Luba,
Madhavan Srinivasan, Michael Ellerman, Mike Leach, Moritz Fischer,
Nicholas Piggin, Russ Weight, Shrikanth Hegde, Suki K Poulose,
Tom Rix, Thomas Weißschuh, Xu Yilun, Yury Norov, Zhang Rui,
coresight, linux-arm-kernel, linux-fpga, linux-pm, linuxppc-dev,
Jakub Kicinski
In-Reply-To: <acJWNRb1t96yu/H6@yilunxu-OptiPlex-7050>
On Tue, Mar 24, 2026 at 05:15:33PM +0800, Xu Yilun wrote:
> On Tue, Mar 03, 2026 at 03:08:41PM -0500, Yury Norov wrote:
> > Switch show_canceled_csk() to use the proper sysfs_emit("%*pbl").
> >
> > Reviewed-by: Russ Weight <russ.weight@linux.dev>
> > Suggested-by: Thomas Weißschuh <linux@weissschuh.net>
> > Signed-off-by: Yury Norov <ynorov@nvidia.com>
> > ---
> > drivers/fpga/intel-m10-bmc-sec-update.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/fpga/intel-m10-bmc-sec-update.c b/drivers/fpga/intel-m10-bmc-sec-update.c
> > index 10f678b9ed36..ae364c6636eb 100644
> > --- a/drivers/fpga/intel-m10-bmc-sec-update.c
> > +++ b/drivers/fpga/intel-m10-bmc-sec-update.c
> > @@ -10,6 +10,7 @@
> > #include <linux/firmware.h>
> > #include <linux/mfd/intel-m10-bmc.h>
> > #include <linux/mod_devicetable.h>
> > +#include <linux/mm.h>
>
> Why add this header file?
When I was preparing the series, I had build issues without this. But
now I checked it against -rc5, and it's clean. Would you like me to
resend?
> > #include <linux/module.h>
> > #include <linux/platform_device.h>
> > #include <linux/slab.h>
> > @@ -183,7 +184,7 @@ show_canceled_csk(struct device *dev, u32 addr, char *buf)
> >
> > bitmap_from_arr32(csk_map, csk32, CSK_BIT_LEN);
> > bitmap_complement(csk_map, csk_map, CSK_BIT_LEN);
> > - return bitmap_print_to_pagebuf(1, buf, csk_map, CSK_BIT_LEN);
> > + return sysfs_emit(buf, "%*pbl\n", CSK_BIT_LEN, csk_map);
> > }
> >
> > #define DEVICE_ATTR_SEC_CSK_RO(_name) \
> > --
> > 2.43.0
> >
> >
^ permalink raw reply
* Re: [PATCH] thermal: intel: int340x: Power Slider: Set offset only for balanced mode
From: Rafael J. Wysocki @ 2026-03-24 18:26 UTC (permalink / raw)
To: Srinivas Pandruvada
Cc: rafael, daniel.lezcano, linux-pm, linux-kernel, Erin Park, stable
In-Reply-To: <20260324172346.3317145-1-srinivas.pandruvada@linux.intel.com>
On Tue, Mar 24, 2026 at 6:23 PM Srinivas Pandruvada
<srinivas.pandruvada@linux.intel.com> wrote:
>
> The slider offset can be set via debugfs for balanced mode. The offset
> should be only applicable in balanced mode. For other modes, it should
> be set 0 when writing to MMIO offset,
>
> Fixes: 8306bcaba06d ("thermal: intel: int340x: Add module parameter to change slider offset")
> Tested-by: Erin Park <erin.park@intel.com>
> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> Cc: stable@vger.kernel.org # v6.18+
> ---
> .../intel/int340x_thermal/processor_thermal_soc_slider.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/thermal/intel/int340x_thermal/processor_thermal_soc_slider.c b/drivers/thermal/intel/int340x_thermal/processor_thermal_soc_slider.c
> index 49ff3bae7271..91f291627132 100644
> --- a/drivers/thermal/intel/int340x_thermal/processor_thermal_soc_slider.c
> +++ b/drivers/thermal/intel/int340x_thermal/processor_thermal_soc_slider.c
> @@ -176,15 +176,21 @@ static inline void write_soc_slider(struct proc_thermal_device *proc_priv, u64 v
>
> static void set_soc_power_profile(struct proc_thermal_device *proc_priv, int slider)
> {
> + u8 offset;
> u64 val;
>
> val = read_soc_slider(proc_priv);
> val &= ~SLIDER_MASK;
> val |= FIELD_PREP(SLIDER_MASK, slider) | BIT(SLIDER_ENABLE_BIT);
>
> + if (slider == SOC_SLIDER_VALUE_MINIMUM || slider == SOC_SLIDER_VALUE_MAXIMUM)
> + offset = 0;
> + else
> + offset = slider_offset;
> +
> /* Set the slider offset from module params */
> val &= ~SLIDER_OFFSET_MASK;
> - val |= FIELD_PREP(SLIDER_OFFSET_MASK, slider_offset);
> + val |= FIELD_PREP(SLIDER_OFFSET_MASK, offset);
>
> write_soc_slider(proc_priv, val);
> }
> --
Applied as 7.0-rc material, thanks!
^ permalink raw reply
* Re: [PATCH] cpufreq: CPPC: add autonomous mode boot parameter support
From: Pierre Gondois @ 2026-03-24 18:18 UTC (permalink / raw)
To: Sumit Gupta
Cc: linux-tegra, linux-kernel, linux-doc, zhenglifeng1, treding,
viresh.kumar, jonathanh, vsethi, ionela.voinescu, ksitaraman,
sanjayc, zhanjie9, nhartman, corbet, mochs, skhan, bbasu, rdunlap,
linux-pm, mario.limonciello, rafael
In-Reply-To: <20260317151053.2361475-1-sumitg@nvidia.com>
Hello Sumit,
On 3/17/26 16:10, Sumit Gupta wrote:
> Add kernel boot parameter 'cppc_cpufreq.auto_sel_mode' to enable CPPC
> autonomous performance selection on all CPUs at system startup without
> requiring runtime sysfs manipulation. When autonomous mode is enabled,
> the hardware automatically adjusts CPU performance based on workload
> demands using Energy Performance Preference (EPP) hints.
>
> When auto_sel_mode=1:
> - Configure all CPUs for autonomous operation on first init
> - Set EPP to performance preference (0x0)
> - Use HW min/max when set; otherwise program from policy limits (caps)
> - Clamp desired_perf to bounds before enabling autonomous mode
> - Hardware controls frequency instead of the OS governor
>
> The boot parameter is applied only during first policy initialization.
> On hotplug, skip applying it so that the user's runtime sysfs
> configuration is preserved.
>
> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> (Documentation)
> Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
> ---
> Part 1 [1] of this series was applied for 7.1 and present in next.
> Sending this patch as reworked version of 'patch 11' from [2] based
> on next.
>
> [1] https://lore.kernel.org/lkml/20260206142658.72583-1-sumitg@nvidia.com/
> [2] https://lore.kernel.org/lkml/20251223121307.711773-1-sumitg@nvidia.com/
> ---
> .../admin-guide/kernel-parameters.txt | 13 +++
> drivers/cpufreq/cppc_cpufreq.c | 84 +++++++++++++++++--
> 2 files changed, 92 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index fa6171b5fdd5..de4b4c89edfe 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1060,6 +1060,19 @@ Kernel parameters
> policy to use. This governor must be registered in the
> kernel before the cpufreq driver probes.
>
> + cppc_cpufreq.auto_sel_mode=
> + [CPU_FREQ] Enable ACPI CPPC autonomous performance
> + selection. When enabled, hardware automatically adjusts
> + CPU frequency on all CPUs based on workload demands.
> + In Autonomous mode, Energy Performance Preference (EPP)
> + hints guide hardware toward performance (0x0) or energy
> + efficiency (0xff).
> + Requires ACPI CPPC autonomous selection register support.
> + Format: <bool>
> + Default: 0 (disabled)
> + 0: use cpufreq governors
> + 1: enable if supported by hardware
> +
> cpu_init_udelay=N
> [X86,EARLY] Delay for N microsec between assert and de-assert
> of APIC INIT to start processors. This delay occurs
> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
> index 5dfb109cf1f4..49c148b2a0a4 100644
> --- a/drivers/cpufreq/cppc_cpufreq.c
> +++ b/drivers/cpufreq/cppc_cpufreq.c
> @@ -28,6 +28,9 @@
>
> static struct cpufreq_driver cppc_cpufreq_driver;
>
> +/* Autonomous Selection boot parameter */
> +static bool auto_sel_mode;
> +
> #ifdef CONFIG_ACPI_CPPC_CPUFREQ_FIE
> static enum {
> FIE_UNSET = -1,
> @@ -708,11 +711,74 @@ static int cppc_cpufreq_cpu_init(struct cpufreq_policy *policy)
> policy->cur = cppc_perf_to_khz(caps, caps->highest_perf);
> cpu_data->perf_ctrls.desired_perf = caps->highest_perf;
>
> - ret = cppc_set_perf(cpu, &cpu_data->perf_ctrls);
> - if (ret) {
> - pr_debug("Err setting perf value:%d on CPU:%d. ret:%d\n",
> - caps->highest_perf, cpu, ret);
> - goto out;
> + /*
> + * Enable autonomous mode on first init if boot param is set.
> + * Check last_governor to detect first init and skip if auto_sel
> + * is already enabled.
> + */
If the goal is to set autosel only once at the driver init,
shouldn't this be done in cppc_cpufreq_init() ?
I understand that cpu_data doesn't exist yet in
cppc_cpufreq_init(), but this seems more appropriate to do
it there IMO.
This means the cpudata should be updated accordingly
in this cppc_cpufreq_cpu_init() function.
> + if (auto_sel_mode && policy->last_governor[0] == '\0' &&
> + !cpu_data->perf_ctrls.auto_sel) {
> + /* Enable CPPC - optional register, some platforms need it */
The documentation of the CPPC Enable Register is subject to
interpretation, but IIUC the field should be set to use the CPPC
controls, so I assume this should be set in cppc_cpufreq_init()
instead ?
> + ret = cppc_set_enable(cpu, true);
> + if (ret && ret != -EOPNOTSUPP)
> + pr_warn("Failed to enable CPPC for CPU%d (%d)\n", cpu, ret);
> +
> + /*
> + * Prefer HW min/max_perf when set; otherwise program from
> + * policy limits derived earlier from caps.
> + * Clamp desired_perf to bounds and sync policy->cur.
> + */
> + if (!cpu_data->perf_ctrls.min_perf || !cpu_data->perf_ctrls.max_perf)
The function doesn't seem to exist.
> + cppc_cpufreq_update_perf_limits(cpu_data, policy);
> +
> + cpu_data->perf_ctrls.desired_perf =
> + clamp_t(u32, cpu_data->perf_ctrls.desired_perf,
> + cpu_data->perf_ctrls.min_perf,
> + cpu_data->perf_ctrls.max_perf);
> +
> + policy->cur = cppc_perf_to_khz(caps,
> + cpu_data->perf_ctrls.desired_perf);
> +
Maybe this should also be done in cppc_cpufreq_init()
if the auto_sel_mode parameter is set ?
> + /* EPP is optional - some platforms may not support it */
> + ret = cppc_set_epp(cpu, CPPC_EPP_PERFORMANCE_PREF);
> + if (ret && ret != -EOPNOTSUPP)
> + pr_warn("Failed to set EPP for CPU%d (%d)\n", cpu, ret);
> + else if (!ret)
> + cpu_data->perf_ctrls.energy_perf = CPPC_EPP_PERFORMANCE_PREF;
> +
> + ret = cppc_set_perf(cpu, &cpu_data->perf_ctrls);
> + if (ret) {
> + pr_debug("Err setting perf for autonomous mode CPU:%d ret:%d\n",
> + cpu, ret);
> + goto out;
> + }
> +
> + ret = cppc_set_auto_sel(cpu, true);
> + if (ret && ret != -EOPNOTSUPP) {
> + pr_warn("Failed autonomous config for CPU%d (%d)\n",
> + cpu, ret);
> + goto out;
> + }
> + if (!ret)
> + cpu_data->perf_ctrls.auto_sel = true;
> + }
> +
> + if (cpu_data->perf_ctrls.auto_sel) {
There is a patchset ongoing which tries to remove
setting policy->min/max from driver initialization.
Indeed, these values are only temporarily valid,
until the governor override them.
It is not sure yet the patch will be accepted though.
https://lore.kernel.org/lkml/20260317101753.2284763-4-pierre.gondois@arm.com/
> + /* Sync policy limits from HW when autonomous mode is active */
> + policy->min = cppc_perf_to_khz(caps,
> + cpu_data->perf_ctrls.min_perf ?:
> + caps->lowest_nonlinear_perf);
> + policy->max = cppc_perf_to_khz(caps,
> + cpu_data->perf_ctrls.max_perf ?:
> + caps->nominal_perf);
> + } else {
> + /* Normal mode: governors control frequency */
> + ret = cppc_set_perf(cpu, &cpu_data->perf_ctrls);
> + if (ret) {
> + pr_debug("Err setting perf value:%d on CPU:%d. ret:%d\n",
> + caps->highest_perf, cpu, ret);
> + goto out;
> + }
> }
>
> cppc_cpufreq_cpu_fie_init(policy);
> @@ -1038,10 +1104,18 @@ static int __init cppc_cpufreq_init(void)
>
> static void __exit cppc_cpufreq_exit(void)
> {
> + unsigned int cpu;
> +
> + for_each_present_cpu(cpu)
> + cppc_set_auto_sel(cpu, false);
If the firmware has a default EPP value, it means that loading
and the unloading the driver will reset this default EPP value.
Maybe the initial EPP value and/or the auto_sel value should be
cached somewhere and restored on exit ?
I don't know if this is actually an issue, this is just to signal it.
> +
> cpufreq_unregister_driver(&cppc_cpufreq_driver);
> cppc_freq_invariance_exit();
> }
>
> +module_param(auto_sel_mode, bool, 0444);
> +MODULE_PARM_DESC(auto_sel_mode, "Enable CPPC autonomous performance selection at boot");
> +
> module_exit(cppc_cpufreq_exit);
> MODULE_AUTHOR("Ashwin Chaugule");
> MODULE_DESCRIPTION("CPUFreq driver based on the ACPI CPPC v5.0+ spec");
^ permalink raw reply
* [PATCH] thermal: intel: int340x: Power Slider: Set offset only for balanced mode
From: Srinivas Pandruvada @ 2026-03-24 17:23 UTC (permalink / raw)
To: rafael, daniel.lezcano
Cc: linux-pm, linux-kernel, Srinivas Pandruvada, Erin Park, stable
The slider offset can be set via debugfs for balanced mode. The offset
should be only applicable in balanced mode. For other modes, it should
be set 0 when writing to MMIO offset,
Fixes: 8306bcaba06d ("thermal: intel: int340x: Add module parameter to change slider offset")
Tested-by: Erin Park <erin.park@intel.com>
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: stable@vger.kernel.org # v6.18+
---
.../intel/int340x_thermal/processor_thermal_soc_slider.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/thermal/intel/int340x_thermal/processor_thermal_soc_slider.c b/drivers/thermal/intel/int340x_thermal/processor_thermal_soc_slider.c
index 49ff3bae7271..91f291627132 100644
--- a/drivers/thermal/intel/int340x_thermal/processor_thermal_soc_slider.c
+++ b/drivers/thermal/intel/int340x_thermal/processor_thermal_soc_slider.c
@@ -176,15 +176,21 @@ static inline void write_soc_slider(struct proc_thermal_device *proc_priv, u64 v
static void set_soc_power_profile(struct proc_thermal_device *proc_priv, int slider)
{
+ u8 offset;
u64 val;
val = read_soc_slider(proc_priv);
val &= ~SLIDER_MASK;
val |= FIELD_PREP(SLIDER_MASK, slider) | BIT(SLIDER_ENABLE_BIT);
+ if (slider == SOC_SLIDER_VALUE_MINIMUM || slider == SOC_SLIDER_VALUE_MAXIMUM)
+ offset = 0;
+ else
+ offset = slider_offset;
+
/* Set the slider offset from module params */
val &= ~SLIDER_OFFSET_MASK;
- val |= FIELD_PREP(SLIDER_OFFSET_MASK, slider_offset);
+ val |= FIELD_PREP(SLIDER_OFFSET_MASK, offset);
write_soc_slider(proc_priv, val);
}
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v5 00/21] Virtual Swap Space
From: Nhat Pham @ 2026-03-24 17:23 UTC (permalink / raw)
To: Askar Safin
Cc: Liam.Howlett, akpm, apopple, axelrasmussen, baohua, baolin.wang,
bhe, byungchul, cgroups, chengming.zhou, chrisl, corbet, david,
dev.jain, gourry, hannes, hughd, jannh, joshua.hahnjy, kasong,
kernel-team, lance.yang, lenb, linux-doc, linux-kernel, linux-mm,
linux-pm, lorenzo.stoakes, matthew.brost, mhocko, muchun.song,
npache, pavel, peterx, peterz, pfalcato, rafael, rakie.kim, riel,
roman.gushchin, rppt, ryan.roberts, shakeel.butt, shikemeng,
surenb, tglx, vbabka, weixugc, ying.huang, yosry.ahmed, yuanchu,
zhengqi.arch, ziy, Kairui Song, Matthew Wilcox
In-Reply-To: <20260324131931.4004123-1-safinaskar@gmail.com>
On Tue, Mar 24, 2026 at 9:19 AM Askar Safin <safinaskar@gmail.com> wrote:
>
> Nhat Pham <nphamcs@gmail.com>:
> > We can even perform compressed writeback
> > (i.e writing these pages without decompressing them) (see [12]).
>
> > [12]: https://lore.kernel.org/linux-mm/ZeZSDLWwDed0CgT3@casper.infradead.org/
>
> This is supported in zram. The support was added here:
> https://lore.kernel.org/all/20251201094754.4149975-1-senozhatsky@chromium.org/ .
> It is already in mainline.
I'm aware of that work. It's an improvement, but my understanding is:
1. It only works for zram.
2. We still occupy the full PAGE_SIZE slot.
3. The writeback IO request is still of size PAGE_SIZE.
So we're saving the CPU work for decompression, but not the rest of
the potential benefits of compressed writeback.
For zswap, decoupling zswap and disk swap is a pre-requisite
(otherwise every zswap slot occupy a PAGE_SIZE slot in the swapfile
anyway).
Then, we have two alternatives. Either we implement a small-slot
allocator for swapfile-infra, or we writeback a full backing page for
compressed memory. The second option is a bit more straightforward,
but then we lose relative age of these objects - a backing page might
combine very recent compressed pages and very old compressed pages.
These approaches have different performance tradeoffs and need to be
evaluated. But anyway this is future work.
^ permalink raw reply
* Re: [PATCH v8 3/9] dax/hmem: Request cxl_acpi and cxl_pci before walking Soft Reserved ranges
From: Dan Williams @ 2026-03-24 16:25 UTC (permalink / raw)
To: Koralahalli Channabasappa, Smita, Dan Williams, Smita Koralahalli,
linux-cxl, linux-kernel, nvdimm, linux-fsdevel, linux-pm
Cc: Ard Biesheuvel, Alison Schofield, Vishal Verma, Ira Weiny,
Jonathan Cameron, Yazen Ghannam, Dave Jiang, Davidlohr Bueso,
Matthew Wilcox, Jan Kara, Rafael J . Wysocki, Len Brown,
Pavel Machek, Li Ming, Jeff Johnson, Ying Huang, Yao Xingtao,
Peter Zijlstra, Greg Kroah-Hartman, Nathan Fontenot, Terry Bowman,
Robert Richter, Benjamin Cheatham, Zhijian Li, Borislav Petkov,
Tomasz Wolski
In-Reply-To: <2960e485-fe26-43b8-a950-9cdb5a090678@amd.com>
Koralahalli Channabasappa, Smita wrote:
[..]
> > As I learned from Keith's recent CXL_PMEM dependency fix for CXL_ACPI
> > [1], this wants to be:
> >
> > depends on DEV_DAX_HMEM || !DEV_DAX_HMEM
> > depends on CXL_ACPI || !CXL_ACPI
> > depends on CXL_PCI || !CXL_PCI
> >
> > ...to make sure that DEV_DAX_CXL can never be built-in unless all of its
> > dependencies are built-in.
> >
> > [1]: http://lore.kernel.org/69aa341fcf526_6423c1002c@dwillia2-mobl4.notmuch
> >
> > At this point I am wondering if all of the feedback I have for this
> > series should just be incremental fixes. I also want to have a canned
> > unit test that verifies the base expectations. That can also be
> > something I reply incrementally.
>
> Two things on the Kconfig change:
>
> When DEV_DAX_HMEM = y and CXL_ACPI = m and CXL_PCI = m
Right, this should not be possible. The patch I am testing moves the
optional CXL dependencies to DEV_DAX_HMEM where they belong. I
mistakenly showed them against DEV_DAX_CXL in my comment.
> 1. Regarding switching from >= to || ! pattern:
>
> The >= pattern disabled DEV_DAX_CXL entirely when DEV_DAX_HMEM = y and
> CXL_ACPI/CXL_PCI = m. So, HMEM unconditionally owned all ranges - the
> CXL deferral path is never entered.
That is one of the broken configurations to fix. It should never be
possible to set DEV_DAX_HMEM=y unless CXL_ACPI and CXL_PCI are both
disabled or both built-in.
> When DEV_DAX_HMEM = y and CXL core is built as a module hmem.c calls
> cxl_region_contains_resource() which lives in cxl_core.ko causing an
> undefined reference at link time.
Yes, I hit this as well and requires another CXL_BUS dependency.
^ permalink raw reply
* Re: [PATCH] cpuidle: Deny idle entry when CPU already have IPI interrupt pending
From: Rafael J. Wysocki @ 2026-03-24 16:07 UTC (permalink / raw)
To: Maulik Shah (mkshah)
Cc: Rafael J. Wysocki, Daniel Lezcano, Christian Loehle, Ulf Hansson,
linux-pm, linux-kernel, linux-arm-msm
In-Reply-To: <fcb05fb8-ed4f-4df1-9aa2-18bc3320cad5@oss.qualcomm.com>
On Mon, Mar 23, 2026 at 1:13 PM Maulik Shah (mkshah)
<maulik.shah@oss.qualcomm.com> wrote:
>
>
>
> On 3/20/2026 11:59 PM, Rafael J. Wysocki wrote:
> > On Mon, Mar 16, 2026 at 8:38 AM Maulik Shah
> > <maulik.shah@oss.qualcomm.com> wrote:
> >>
> >> CPU can get IPI interrupt from another CPU while it is executing
> >> cpuidle_select() or about to execute same. The selection do not account
> >> for pending interrupts and may continue to enter selected idle state only
> >> to exit immediately.
> >>
> >> Example trace collected when there is cross CPU IPI.
> >>
> >> [000] 154.892148: sched_waking: comm=sugov:4 pid=491 prio=-1 target_cpu=007
> >> [000] 154.892148: ipi_raise: target_mask=00000000,00000080 (Function call interrupts)
> >> [007] 154.892162: cpu_idle: state=2 cpu_id=7
> >> [007] 154.892208: cpu_idle: state=4294967295 cpu_id=7
> >> [007] 154.892211: irq_handler_entry: irq=2 name=IPI
> >> [007] 154.892211: ipi_entry: (Function call interrupts)
> >> [007] 154.892213: sched_wakeup: comm=sugov:4 pid=491 prio=-1 target_cpu=007
> >> [007] 154.892214: ipi_exit: (Function call interrupts)
> >>
> >> This impacts performance and the above count increments.
> >>
> >> commit ccde6525183c ("smp: Introduce a helper function to check for pending
> >> IPIs") already introduced a helper function to check the pending IPIs and
> >> it is used in pmdomain governor to deny the cluster level idle state when
> >> there is a pending IPI on any of cluster CPUs.
> >
> > You seem to be overlooking the fact that resched wakeups need not be
> > signaled via IPIs, but they may be updates of a monitored cache line.
> >
> >> This however does not stop CPU to enter CPU level idle state. Make use of
> >> same at CPUidle to deny the idle entry when there is already IPI pending.
> >>
> >> With change observing glmark2 [1] off screen scores improving in the range
> >> of 25% to 30% on Qualcomm lemans-evk board which is arm64 based having two
> >> clusters each with 4 CPUs.
> >>
> >> [1] https://github.com/glmark2/glmark2
> >>
> >> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
> >> ---
> >> drivers/cpuidle/cpuidle.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> >> index c7876e9e024f9076663063ad21cfc69343fdbbe7..c88c0cbf910d6c2c09697e6a3ac78c081868c2ad 100644
> >> --- a/drivers/cpuidle/cpuidle.c
> >> +++ b/drivers/cpuidle/cpuidle.c
> >> @@ -224,6 +224,9 @@ noinstr int cpuidle_enter_state(struct cpuidle_device *dev,
> >> bool broadcast = !!(target_state->flags & CPUIDLE_FLAG_TIMER_STOP);
> >> ktime_t time_start, time_end;
> >>
> >> + if (cpus_peek_for_pending_ipi(drv->cpumask))
> >> + return -EBUSY;
> >> +
> >
> > So what if the driver handles all CPUs in the system and there are
> > many of them (say ~500) and if IPIs occur rarely (because resched
> > events are not IPIs)?
>
> Missed the case of driver handling multiple CPUs,
> In v2 would fix this as below, which checks pending IPI on single
> CPU trying to enter idle.
>
> if (cpus_peek_for_pending_ipi(cpumask_of(dev->cpu)))
And the for_each_cpu() loop in cpus_peek_for_pending_ipi() would then
become useless overhead, wouldn't ir?
> I see IPIs do occur often, in the glmark2 offscreen case
> mentioned in commit text, out of total ~12.2k IPIs across all 8 CPUs,
> ~9.6k are function call IPIs, ~2k are IRQ work IPIs, ~560 Timer broadcast
> IPIs while rescheduling IPIs are only 82.
So how many of those IPIs actually wake up CPUs from idle prematurely?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox