* [PATCH net-next v3 1/3] dpll: add frequency monitoring to netlink spec
From: Ivan Vecera @ 2026-04-01 9:12 UTC (permalink / raw)
To: netdev
Cc: Vadim Fedorenko, Arkadiusz Kubalewski, David S. Miller,
Donald Hunter, Eric Dumazet, Jakub Kicinski, Jiri Pirko,
Jonathan Corbet, Michal Schmidt, Paolo Abeni, Petr Oros,
Prathosh Satish, Shuah Khan, Simon Horman, linux-doc,
linux-kernel
In-Reply-To: <20260401091237.1071995-1-ivecera@redhat.com>
Add DPLL_A_FREQUENCY_MONITOR device attribute to allow control over
the frequency monitor feature. The attribute uses the existing
dpll_feature_state enum (enable/disable) and is present in both
device-get reply and device-set request.
Add DPLL_A_PIN_MEASURED_FREQUENCY pin attribute to expose the measured
input frequency in millihertz (mHz). The attribute is present in the
pin-get reply. Add DPLL_PIN_MEASURED_FREQUENCY_DIVIDER constant to
allow userspace to extract integer and fractional parts.
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
Changes v2 -> v3:
- Improved frequency-monitor doc wording (Jakub)
- Changed measured-frequency to mHz with divider constant (Jakub)
Changes v1 -> v2:
- Renamed actual-frequency to measured-frequency (Vadim)
---
Documentation/driver-api/dpll.rst | 20 +++++++++++++++
Documentation/netlink/specs/dpll.yaml | 35 +++++++++++++++++++++++++++
drivers/dpll/dpll_nl.c | 5 ++--
include/uapi/linux/dpll.h | 5 +++-
4 files changed, 62 insertions(+), 3 deletions(-)
diff --git a/Documentation/driver-api/dpll.rst b/Documentation/driver-api/dpll.rst
index 83118c728ed90..93c191b2d0898 100644
--- a/Documentation/driver-api/dpll.rst
+++ b/Documentation/driver-api/dpll.rst
@@ -250,6 +250,24 @@ in the ``DPLL_A_PIN_PHASE_OFFSET`` attribute.
``DPLL_A_PHASE_OFFSET_MONITOR`` attr state of a feature
=============================== ========================
+Frequency monitor
+=================
+
+Some DPLL devices may offer the capability to measure the actual
+frequency of all available input pins. The attribute and current feature state
+shall be included in the response message of the ``DPLL_CMD_DEVICE_GET``
+command for supported DPLL devices. In such cases, users can also control
+the feature using the ``DPLL_CMD_DEVICE_SET`` command by setting the
+``enum dpll_feature_state`` values for the attribute.
+Once enabled the measured input frequency for each input pin shall be
+returned in the ``DPLL_A_PIN_MEASURED_FREQUENCY`` attribute. The value
+is in millihertz (mHz), using ``DPLL_PIN_MEASURED_FREQUENCY_DIVIDER``
+as the divider.
+
+ =============================== ========================
+ ``DPLL_A_FREQUENCY_MONITOR`` attr state of a feature
+ =============================== ========================
+
Embedded SYNC
=============
@@ -411,6 +429,8 @@ according to attribute purpose.
``DPLL_A_PIN_STATE`` attr state of pin on the parent
pin
``DPLL_A_PIN_CAPABILITIES`` attr bitmask of pin capabilities
+ ``DPLL_A_PIN_MEASURED_FREQUENCY`` attr measured frequency of
+ an input pin in mHz
==================================== ==================================
==================================== =================================
diff --git a/Documentation/netlink/specs/dpll.yaml b/Documentation/netlink/specs/dpll.yaml
index 3dd48a32f7837..40465a3d7fc20 100644
--- a/Documentation/netlink/specs/dpll.yaml
+++ b/Documentation/netlink/specs/dpll.yaml
@@ -240,6 +240,20 @@ definitions:
integer part of a measured phase offset value.
Value of (DPLL_A_PHASE_OFFSET % DPLL_PHASE_OFFSET_DIVIDER) is a
fractional part of a measured phase offset value.
+ -
+ type: const
+ name: pin-measured-frequency-divider
+ value: 1000
+ doc: |
+ pin measured frequency divider allows userspace to calculate
+ a value of measured input frequency as a fractional value with
+ three digit decimal precision (millihertz).
+ Value of (DPLL_A_PIN_MEASURED_FREQUENCY /
+ DPLL_PIN_MEASURED_FREQUENCY_DIVIDER) is an integer part of
+ a measured frequency value.
+ Value of (DPLL_A_PIN_MEASURED_FREQUENCY %
+ DPLL_PIN_MEASURED_FREQUENCY_DIVIDER) is a fractional part of
+ a measured frequency value.
-
type: enum
name: feature-state
@@ -319,6 +333,13 @@ attribute-sets:
name: phase-offset-avg-factor
type: u32
doc: Averaging factor applied to calculation of reported phase offset.
+ -
+ name: frequency-monitor
+ type: u32
+ enum: feature-state
+ doc: Current or desired state of the frequency monitor feature.
+ If enabled, dpll device shall measure all currently available
+ inputs for their actual input frequency.
-
name: pin
enum-name: dpll_a_pin
@@ -456,6 +477,17 @@ attribute-sets:
Value is in PPT (parts per trillion, 10^-12).
Note: This attribute provides higher resolution than the standard
fractional-frequency-offset (which is in PPM).
+ -
+ name: measured-frequency
+ type: u64
+ doc: |
+ The measured frequency of the input pin in millihertz (mHz).
+ Value of (DPLL_A_PIN_MEASURED_FREQUENCY /
+ DPLL_PIN_MEASURED_FREQUENCY_DIVIDER) is an integer part (Hz)
+ of a measured frequency value.
+ Value of (DPLL_A_PIN_MEASURED_FREQUENCY %
+ DPLL_PIN_MEASURED_FREQUENCY_DIVIDER) is a fractional part
+ of a measured frequency value.
-
name: pin-parent-device
@@ -544,6 +576,7 @@ operations:
- type
- phase-offset-monitor
- phase-offset-avg-factor
+ - frequency-monitor
dump:
reply: *dev-attrs
@@ -563,6 +596,7 @@ operations:
- mode
- phase-offset-monitor
- phase-offset-avg-factor
+ - frequency-monitor
-
name: device-create-ntf
doc: Notification about device appearing
@@ -643,6 +677,7 @@ operations:
- esync-frequency-supported
- esync-pulse
- reference-sync
+ - measured-frequency
dump:
request:
diff --git a/drivers/dpll/dpll_nl.c b/drivers/dpll/dpll_nl.c
index a2b22d4921142..1e652340a5d73 100644
--- a/drivers/dpll/dpll_nl.c
+++ b/drivers/dpll/dpll_nl.c
@@ -43,11 +43,12 @@ static const struct nla_policy dpll_device_get_nl_policy[DPLL_A_ID + 1] = {
};
/* DPLL_CMD_DEVICE_SET - do */
-static const struct nla_policy dpll_device_set_nl_policy[DPLL_A_PHASE_OFFSET_AVG_FACTOR + 1] = {
+static const struct nla_policy dpll_device_set_nl_policy[DPLL_A_FREQUENCY_MONITOR + 1] = {
[DPLL_A_ID] = { .type = NLA_U32, },
[DPLL_A_MODE] = NLA_POLICY_RANGE(NLA_U32, 1, 2),
[DPLL_A_PHASE_OFFSET_MONITOR] = NLA_POLICY_MAX(NLA_U32, 1),
[DPLL_A_PHASE_OFFSET_AVG_FACTOR] = { .type = NLA_U32, },
+ [DPLL_A_FREQUENCY_MONITOR] = NLA_POLICY_MAX(NLA_U32, 1),
};
/* DPLL_CMD_PIN_ID_GET - do */
@@ -115,7 +116,7 @@ static const struct genl_split_ops dpll_nl_ops[] = {
.doit = dpll_nl_device_set_doit,
.post_doit = dpll_post_doit,
.policy = dpll_device_set_nl_policy,
- .maxattr = DPLL_A_PHASE_OFFSET_AVG_FACTOR,
+ .maxattr = DPLL_A_FREQUENCY_MONITOR,
.flags = GENL_ADMIN_PERM | GENL_CMD_CAP_DO,
},
{
diff --git a/include/uapi/linux/dpll.h b/include/uapi/linux/dpll.h
index de0005f28e5c5..871685f7c353b 100644
--- a/include/uapi/linux/dpll.h
+++ b/include/uapi/linux/dpll.h
@@ -191,7 +191,8 @@ enum dpll_pin_capabilities {
DPLL_PIN_CAPABILITIES_STATE_CAN_CHANGE = 4,
};
-#define DPLL_PHASE_OFFSET_DIVIDER 1000
+#define DPLL_PHASE_OFFSET_DIVIDER 1000
+#define DPLL_PIN_MEASURED_FREQUENCY_DIVIDER 1000
/**
* enum dpll_feature_state - Allow control (enable/disable) and status checking
@@ -218,6 +219,7 @@ enum dpll_a {
DPLL_A_CLOCK_QUALITY_LEVEL,
DPLL_A_PHASE_OFFSET_MONITOR,
DPLL_A_PHASE_OFFSET_AVG_FACTOR,
+ DPLL_A_FREQUENCY_MONITOR,
__DPLL_A_MAX,
DPLL_A_MAX = (__DPLL_A_MAX - 1)
@@ -254,6 +256,7 @@ enum dpll_a_pin {
DPLL_A_PIN_REFERENCE_SYNC,
DPLL_A_PIN_PHASE_ADJUST_GRAN,
DPLL_A_PIN_FRACTIONAL_FREQUENCY_OFFSET_PPT,
+ DPLL_A_PIN_MEASURED_FREQUENCY,
__DPLL_A_PIN_MAX,
DPLL_A_PIN_MAX = (__DPLL_A_PIN_MAX - 1)
--
2.52.0
^ permalink raw reply related
* Re: [PATCH 3/5] compiler_attributes: Add overflow_behavior macros __ob_trap and __ob_wrap
From: Peter Zijlstra @ 2026-04-01 9:08 UTC (permalink / raw)
To: Kees Cook
Cc: Justin Stitt, Miguel Ojeda, Marco Elver, Andrey Konovalov,
Andrey Ryabinin, Jonathan Corbet, Shuah Khan, Miguel Ojeda,
Nathan Chancellor, kasan-dev, linux-doc, llvm, Linus Torvalds,
Nicolas Schier, Arnd Bergmann, Greg Kroah-Hartman, Andrew Morton,
linux-kernel, linux-hardening, linux-kbuild
In-Reply-To: <202603311249.30B44C66@keescook>
On Tue, Mar 31, 2026 at 12:52:10PM -0700, Kees Cook wrote:
> I think for this series, __ob_trap/__ob_wrap is what should be used.
>
> And for other folks, the background here is that we originally wanted
> to use macros for "__trap" and "__wrap", but the powerpc C compiler
> (both Clang and GCC) have a builtin macro named "__trap" already. So
> I switched to just using the Clang-native type qualifier. We can use
> the attribute style too, but there was a lot of confusion during the
> Clang development phases where people kept forgetting this was a type
> qualifier, not an attribute (i.e. the attribute is an internal alias
> for the qualifier, and the qualifier is a new type).
Since you mention qualifiers...
What is the result of __typeof_unqual__(int __ob_trap) ?
^ permalink raw reply
* Re: [PATCH v8 02/10] x86/bhi: Make clear_bhb_loop() effective on newer CPUs
From: David Laight @ 2026-04-01 9:02 UTC (permalink / raw)
To: Pawan Gupta
Cc: Borislav Petkov, x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin,
Josh Poimboeuf, David Kaplan, Sean Christopherson, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
Andy Lutomirski, Thomas Gleixner, Ingo Molnar, David Ahern,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, Stanislav Fomichev, Hao Luo, Paolo Bonzini,
Jonathan Corbet, linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf,
netdev, linux-doc
In-Reply-To: <20260401081236.3rjp2wigkr6w3nym@desk>
On Wed, 1 Apr 2026 01:12:36 -0700
Pawan Gupta <pawan.kumar.gupta@linux.intel.com> wrote:
> On Sat, Mar 28, 2026 at 10:08:37AM +0000, David Laight wrote:
> > On Fri, 27 Mar 2026 17:42:56 -0700
> > Pawan Gupta <pawan.kumar.gupta@linux.intel.com> wrote:
> >
> > > On Thu, Mar 26, 2026 at 01:29:31PM -0700, Pawan Gupta wrote:
> > > > On Thu, Mar 26, 2026 at 10:45:57AM +0000, David Laight wrote:
> > > > > On Thu, 26 Mar 2026 11:01:20 +0100
> > > > > Borislav Petkov <bp@alien8.de> wrote:
> > > > >
> > > > > > On Thu, Mar 26, 2026 at 01:39:34AM -0700, Pawan Gupta wrote:
> > > > > > > I believe the equivalent for cpu_feature_enabled() in asm is the
> > > > > > > ALTERNATIVE. Please let me know if I am missing something.
> > > > > >
> > > > > > Yes, you are.
> > > > > >
> > > > > > The point is that you don't want to stick those alternative calls inside some
> > > > > > magic bhb_loop function but hand them in from the outside, as function
> > > > > > arguments.
> > > > > >
> > > > > > Basically what I did.
> > > > > >
> > > > > > Then you were worried about this being C code and it had to be noinstr... So
> > > > > > that outer function can be rewritten in asm, I think, and still keep it well
> > > > > > separate.
> > > > > >
> > > > > > I'll try to rewrite it once I get a free minute, and see how it looks.
> > > > > >
> > > > >
> > > > > I think someone tried getting C code to write the values to global data
> > > > > and getting the asm to read them.
> > > > > That got discounted because it spilt things between two largely unrelated files.
> > > >
> > > >
> > > > The implementation with global variables wasn't that bad, let me revive it.
> > > >
> > > > This part which ties sequence to BHI mitigation, which is not ideal,
> > > > (because VMSCAPE also uses it) it does seems a cleaner option.
> > > >
> > > > --- a/arch/x86/kernel/cpu/bugs.c
> > > > +++ b/arch/x86/kernel/cpu/bugs.c
> > > > @@ -2095,6 +2095,11 @@ static void __init bhi_select_mitigation(void)
> > > >
> > > > static void __init bhi_update_mitigation(void)
> > > > {
> > > > + if (!cpu_feature_enabled(X86_FEATURE_BHI_CTRL)) {
> > > > + bhi_seq_outer_loop = 5;
> > > > + bhi_seq_inner_loop = 5;
> > > > + }
> > > > +
> > > >
> > > > I believe this can be moved to somewhere common to all mitigations.
> > > >
> > > > > I think the BPF code would need significant refactoring to call a C function.
> > > >
> > > > Ya, true. Will use globals and keep clear_bhb_loop() in asm.
> > >
> > > While testing this approach, I noticed that syscalls were suffering an 8%
> > > regression on ICX for Native BHI mitigation:
> > >
> > > $ perf bench syscall basic -l 100000000
> > >
> > > Bisection pointed to the change for using 8-bit registers (al/ah replacing
> > > eax/ecx) as the main contributor to the regression. (Global variables added
> > > a bit, but within noise).
> > >
> > > Further digging revealed a strange behavior, using %ah for the inner loop
> > > was causing the regression, interchanging %al and %ah in the loops
> > > (for movb and sub) eliminated the regression.
> > >
> > > <clear_bhb_loop_nofence>:
> > >
> > > movb bhb_seq_outer_loop(%rip), %al
> > >
> > > call 1f
> > > jmp 5f
> > > 1: call 2f
> > > .Lret1: RET
> > > 2: movb bhb_seq_inner_loop(%rip), %ah
> > > 3: jmp 4f
> > > nop
> > > 4: sub $1, %ah <---- No regression with %al here
> > > jnz 3b
> > > sub $1, %al
> > > jnz 1b
> > >
> > > My guess is, "sub $1, %al" is faster than "sub $1, %ah". Using %al in the
> > > inner loop, which is executed more number of times is likely making the
> > > difference. A perf profile is needed to confirm this.
> >
> > I bet it is also CPU dependant - it is quite likely that there isn't
> > any special hardware to support partial writes of %ah so it ends up taking
> > a slow path (possibly even a microcoded one to get an 8% regression).
>
> Strangely, %ah in the inner loop incurs less uops and has fewer branch
> misses, yet takes more cycles. Below is the perf data for the sequence on a
> Rocket Lake (similar observation on ICX and EMR):
>
> Event %al inner %ah inner Delta
> ---------------------- ------------- ------------- ----------
> cycles 776,775,020 972,322,384 +25.2%
> instructions/cycle 1.23 0.98 -20.3%
> branch-misses 4,792,502 560,449 -88.3%
> uops_issued.any 768,019,010 696,888,357 -9.3%
> time elapsed 0.1627s 0.2048s +25.9%
>
> Time elapsed directly correlates with the increase in cycles.
That might be consistent with the %ah accesses (probably writes)
being very slow/synchronising.
So you are getting a full cpu stall instead speculative execution
of the following instructions - which must include a lot of mis-predicted
branches.
> > As well as swapping %al <-> %ah try changing the outer loop decrement to
> > sub $0x100, %ax
> > since %al is zero that will set the z flag the same.
>
> Unfortunately, using "sub $0x100, %ax"(with %al as inner loop) isn't better
> than just using "sub $1, %ah" in the outer loop:
>
> Event %al inner + sub %ax Delta
> ---------------------- ------------- ------------- ----------
> cycles 776,775,020 813,372,036 +4.7%
> instructions/cycle 1.23 1.17 -4.5%
> branch-misses 4,792,502 7,610,323 +58.8%
> uops_issued.any 768,019,010 827,465,137 +7.7%
> time elapsed 0.1627s 0.1707s +4.9%
That is even more interesting.
The 'sub %ax' version has more uops and more branch-misses.
Looks like the extra cost of the %ah access is less than the cost
of the extra mis-predicted branches.
Makes me wonder where a version that uses %cl fits?
(Or use a zero-extending read and %eax/%ecx - likely to be the same.)
I'll bet 'one beer' that is nearest the 'sub %ax' version.
David
>
> > I've just hacked a test into some test code I've got.
> > I'm not seeing an unexpected costs on either zen-5 or haswell.
> > So it may be more subtle.
>
> This is puzzling, but atleast it is evident that using %al for the inner
> loop seems to be the best option. In summary:
>
> Variant Cycles Uops Issued Branch Misses
> ------- ---------- ----------- -------------
> %al 776M 768M 4.8M (fastest)
> %ah 972M (+25%) 697M (-9%) 560K (-88%) (fewer uops + misses, yet slowest)
> sub %ax 813M (+5%) 827M (+8%) 7.6M (+59%) (most uops + misses)
^ permalink raw reply
* Re: [PATCH 5/5] types: Add standard __ob_trap and __ob_wrap scalar types
From: Peter Zijlstra @ 2026-04-01 8:57 UTC (permalink / raw)
To: Kees Cook
Cc: Linus Torvalds, Justin Stitt, Miguel Ojeda, Nathan Chancellor,
Andrew Morton, Andy Shevchenko, Arnd Bergmann, Mark Rutland,
Matthew Wilcox (Oracle), Suren Baghdasaryan, Thomas Gleixner,
Finn Thain, Geert Uytterhoeven, Thomas Weißschuh, llvm,
Marco Elver, Jonathan Corbet, Nicolas Schier, Greg Kroah-Hartman,
linux-kernel, kasan-dev, linux-hardening, linux-doc, linux-kbuild
In-Reply-To: <202603311321.4EE9FEA@keescook>
On Tue, Mar 31, 2026 at 01:31:16PM -0700, Kees Cook wrote:
> int func()
> {
> ...
> u8 __ob_trap product = 5;
> ...
> product = a * b; // if store is truncated, goto __overflow
> ...
> return product;
>
> __overflow:
> pr_info("%u\n", product); // shows "5"
I'm confused by this 'product is still 5' thing. It seems to me that
making this happen will, in general, require more instructions/registers
than allowing the old value to be clobbered and have product be the
truncated result of whatever overflow.
Specifically, what is the value of preserving the old value?
> return -1;
> }
^ permalink raw reply
* Re: [PATCH 5/5] types: Add standard __ob_trap and __ob_wrap scalar types
From: Peter Zijlstra @ 2026-04-01 8:31 UTC (permalink / raw)
To: Kees Cook
Cc: Linus Torvalds, Justin Stitt, Miguel Ojeda, Nathan Chancellor,
Andrew Morton, Andy Shevchenko, Arnd Bergmann, Mark Rutland,
Matthew Wilcox (Oracle), Suren Baghdasaryan, Thomas Gleixner,
Finn Thain, Geert Uytterhoeven, Thomas Weißschuh, llvm,
Marco Elver, Jonathan Corbet, Nicolas Schier, Greg Kroah-Hartman,
linux-kernel, kasan-dev, linux-hardening, linux-doc, linux-kbuild
In-Reply-To: <202603311321.4EE9FEA@keescook>
On Tue, Mar 31, 2026 at 01:31:16PM -0700, Kees Cook wrote:
(still slowly digesting the thread)
> Yeah, as you mentioned earlier, I'd agree that nesting is rarely
> useful. The only thing I'd want to be careful about is ordering/scope. I
> *think* it would just operate as a "goto" and things like the cleanup.h
> handlers wouldn't be involved: they operate when a scope is crossed
> like before. And I think the overflow result wouldn't be represented
> anywhere. i.e. the wrapped/truncated value wouldn't be stored:
>
> int func()
> {
> ...
> u8 __ob_trap product = 5;
> ...
> product = a * b; // if store is truncated, goto __overflow
> ...
> return product;
>
> __overflow:
> pr_info("%u\n", product); // shows "5"
> return -1;
> }
Note that there is a 'fun' problem with this in combination with
cleanup.h.
Something like:
int func()
{
u8 __ob_trap prod = 0;
scoped_guard (mutex, &my_lock) {
prod = a * b;
}
return prod;
__overflow:
// whatever
return -1;
}
is fine. *HOWEVER*, something like:
int func()
{
int __ob_trap size = base + count * extra;
int err;
struct my_obj *obj __cleanup(kfree) = kzalloc(size, GFP_KERNEL);
err = my_obj_init(obj);
if (err)
return ERR_PTR(err);
return_ptr(obj);
__overflow:
// what now..
return NULL;
}
is most terribly broken. Specifically, the goto will jump into the scope
of obj -- and that is not allowed.
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Michel Dänzer @ 2026-04-01 8:27 UTC (permalink / raw)
To: Nicolas Frattaroli, Ville Syrjälä, Dave Stevenson
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc, Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <7991520.DvuYhMxLoT@workhorse>
On 3/26/26 13:02, Nicolas Frattaroli wrote:
> On Thursday, 26 March 2026 12:16:12 Central European Standard Time Dave Stevenson wrote:
>> On Wed, 25 Mar 2026 at 13:43, Ville Syrjälä
>> <ville.syrjala@linux.intel.com> wrote:
>>> On Wed, Mar 25, 2026 at 12:49:19PM +0000, Dave Stevenson wrote:
>>>> On Tue, 24 Mar 2026 at 16:02, Nicolas Frattaroli
>>>> <nicolas.frattaroli@collabora.com> wrote:
>>>>>
>>>>> +/**
>>>>> + * enum drm_connector_color_format - Connector Color Format Request
>>>>> + *
>>>>> + * This enum, unlike &enum drm_output_color_format, is used to specify requests
>>>>> + * for a specific color format on a connector through the DRM "color format"
>>>>> + * property. The difference is that it has an "AUTO" value to specify that
>>>>> + * no specific choice has been made.
>>>>> + */
>>>>> +enum drm_connector_color_format {
>>>>> + /**
>>>>> + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
>>>>> + * helpers should pick a suitable color format. All implementations of a
>>>>> + * specific display protocol must behave the same way with "AUTO", but
>>>>> + * different display protocols do not necessarily have the same "AUTO"
>>>>> + * semantics.
>>>>> + *
>>>>> + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
>>>>> + * bandwidth required for full-scale RGB is not available, or the mode
>>>>> + * is YCbCr 4:2:0-only, as long as the mode and output both support
>>>>> + * YCbCr 4:2:0.
>>>>
>>>> Is there a reason you propose dropping back to YCbCr 4:2:0 without
>>>> trying YCbCr 4:2:2 first? Minimising the subsampling is surely
>>>> beneficial, and vc4 for one can do 4:2:2 but not 4:2:0.
>>>
>>> On HDMI 4:2:2 is always 12bpc, so it doesn't save any bandwidth
>>> compared to 8bpc 4:4:4.
>>
>> It does save bandwidth against 10 or 12bpc RGB 4:4:4.
>>
>> Or is the implication that max_bpc = 12 and
>> DRM_CONNECTOR_COLOR_FORMAT_AUTO should drop bpc down to 8 and select
>> RGB in preference to selecting 4:2:2?
>
> Yes. Some people consider max-bpc to not be a legitimate way of requesting
> an actual bpc, and don't think drivers will choose the highest bpc <= max-bpc,
> and instead may negotiate a fantasy number anywhere below or equal to max-bpc.
Ridiculing others like this for disagreeing with you is uncalled for.
Is there any evidence for your claim that the driver must always use the
highest possible bpc <= max-bpc?
> Of course this logic could be done in userspace which knows whether the
> less chroma for more bit depth trade-off is worth it, but userspace does
> not know the negotiated link bpc, and my attempts at adding a property for
> it are being blocked.
Assuming you're referring to the concerns I raised there, I don't have the power or intent to block it.
--
Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer
https://redhat.com \ Libre software enthusiast
^ permalink raw reply
* Re: [PATCH v10 02/21] gpu: nova-core: gsp: Extract usable FB region from GSP
From: Eliot Courtney @ 2026-04-01 8:27 UTC (permalink / raw)
To: Joel Fernandes, linux-kernel
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Dave Airlie, Daniel Almeida, Koen Koning, dri-devel,
rust-for-linux, Nikola Djukic, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellstrom, Helge Deller,
Alex Gaynor, Boqun Feng, John Hubbard, Alistair Popple,
Timur Tabi, Edwin Peer, Alexandre Courbot, Andrea Righi,
Andy Ritger, Zhi Wang, Balbir Singh, Philipp Stanner,
Elle Rhumsaa, alexeyi, Eliot Courtney, joel, linux-doc, amd-gfx,
intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <20260331212048.2229260-3-joelagnelf@nvidia.com>
On Wed Apr 1, 2026 at 6:20 AM JST, Joel Fernandes wrote:
> Add first_usable_fb_region() to GspStaticConfigInfo to extract the first
> usable FB region from GSP's fbRegionInfoParams. Usable regions are those
> that are not reserved or protected.
>
> The extracted region is stored in GetGspStaticInfoReply and exposed as
> usable_fb_region field for use by the memory subsystem.
>
> Cc: Nikola Djukic <ndjukic@nvidia.com>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
Please see my feedback from v9[1] which still applies.
[1]: https://lore.kernel.org/all/DH1GK30TUB4V.2GR6ANXIZDFFQ@nvidia.com/
thanks
^ permalink raw reply
* Re: [PATCH v10 01/21] gpu: nova-core: gsp: Return GspStaticInfo from boot()
From: Eliot Courtney @ 2026-04-01 8:25 UTC (permalink / raw)
To: Joel Fernandes, linux-kernel
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Dave Airlie, Daniel Almeida, Koen Koning, dri-devel,
rust-for-linux, Nikola Djukic, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellstrom, Helge Deller,
Alex Gaynor, Boqun Feng, John Hubbard, Alistair Popple,
Timur Tabi, Edwin Peer, Alexandre Courbot, Andrea Righi,
Andy Ritger, Zhi Wang, Balbir Singh, Philipp Stanner,
Elle Rhumsaa, alexeyi, Eliot Courtney, joel, linux-doc, amd-gfx,
intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <20260331212048.2229260-2-joelagnelf@nvidia.com>
On Wed Apr 1, 2026 at 6:20 AM JST, Joel Fernandes wrote:
> Refactor the GSP boot function to return only the GspStaticInfo,
> removing the FbLayout from the return tuple.
>
> This enables access required for memory management initialization to:
> - bar1_pde_base: BAR1 page directory base.
> - bar2_pde_base: BAR2 page directory base.
> - usable memory regions in vidmem.
>
> Cc: Nikola Djukic <ndjukic@nvidia.com>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
Please see my feedback from v9[1] which still applies.
[1]: https://lore.kernel.org/all/DH0LH3D38CZ1.2DK8BN4CMU4FW@nvidia.com/
^ permalink raw reply
* Re: [PATCH v10 0/8] ACPI: Unify CPU UID interface and fix ARM64 TPH steer-tag issue
From: fengchengwen @ 2026-04-01 8:22 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Bjorn Helgaas, Catalin Marinas, Will Deacon, Jonathan Corbet,
Palmer Dabbelt, Borislav Petkov, H . Peter Anvin, Juergen Gross,
Boris Ostrovsky, Sunil V L, Mark Rutland, Jonathan Cameron,
Kees Cook, Yanteng Si, Sean Christopherson, Kai Huang,
Tom Lendacky, Thomas Huth, Thorsten Blum, Kevin Loughlin,
Zheyun Shen, Peter Zijlstra, Pawan Gupta, Xin Li,
Ahmed S . Darwish, Sohil Mehta, Ilkka Koskinen, Robin Murphy,
James Clark, Besar Wicaksono, Ma Ke, Wei Huang, Andy Gospodarek,
Somnath Kotur, punit.agrawal, guohanjun, suzuki.poulose,
ryan.roberts, chenl311, masahiroy, wangyuquan1236,
anshuman.khandual, heinrich.schuchardt, Eric.VanTassell,
wangzhou1, wanghuiqiang, liuyonglong, linux-pci, linux-doc,
linux-kernel, linux-arm-kernel, loongarch, linux-riscv, xen-devel,
linux-acpi, linux-perf-users
In-Reply-To: <CAJZ5v0gO1VSPs58JeupaiTZBkP3i_-H2bEQpfU-6k2TXjdiaOQ@mail.gmail.com>
On 3/31/2026 8:24 PM, Rafael J. Wysocki wrote:
> On Fri, Mar 20, 2026 at 4:17 AM Chengwen Feng <fengchengwen@huawei.com> wrote:
>>
>> This patchset unifies ACPI Processor UID retrieval across
>> arm64/loongarch/riscv/x86 via acpi_get_cpu_uid() (with input validation)
>> and fixes ARM64 CPU steer-tag retrieval failure in PCI/TPH:
>>
>> 1-4: Add acpi_get_cpu_uid() for arm64/loongarch/riscv/x86 (update
>> respective users)
>> 5: Centralize acpi_get_cpu_uid() declaration in include/linux/acpi.h
>> 6: Clean up perf/arm_cspmu
>> 7: Clean up ACPI/PPTT and remove unused get_acpi_id_for_cpu()
>> 8: Pass ACPI Processor UID to Cache Locality _DSM
>>
>> The interface refactor ensures consistent CPU UID retrieval across
>> architectures (no functional changes for valid inputs) and provides the
>> unified interface required for the ARM64 TPH fix.
>>
>> ---
>> Changes in v10:
>> - Refine commit header&log according to Punit's and Bjorn's review
>> - Split perf/arm_cspmu as a separate commit which address Punit's
>> review
>>
>> Changes in v9:
>> - Address Bjorn's review: split commits to each platform so that make
>> them easy to review
>>
>> Changes in v8:
>> - Moving arm64's get_cpu_for_acpi_id() to kernel/acpi.c which address
>> Jeremy's review
>>
>> Chengwen Feng (8):
>> arm64: acpi: Add acpi_get_cpu_uid() for unified ACPI CPU UID retrieval
>> LoongArch: Add acpi_get_cpu_uid() for unified ACPI CPU UID retrieval
>> RISC-V: ACPI: Add acpi_get_cpu_uid() for unified ACPI CPU UID
>> retrieval
>> x86/acpi: Add acpi_get_cpu_uid() for unified ACPI CPU UID retrieval
>> ACPI: Centralize acpi_get_cpu_uid() declaration in
>> include/linux/acpi.h
>> perf: arm_cspmu: Switch to acpi_get_cpu_uid() from
>> get_acpi_id_for_cpu()
>> ACPI: PPTT: Use acpi_get_cpu_uid() and remove get_acpi_id_for_cpu()
>> PCI/TPH: Pass ACPI Processor UID to Cache Locality _DSM
>>
>> Documentation/PCI/tph.rst | 4 +--
>> arch/arm64/include/asm/acpi.h | 17 +---------
>> arch/arm64/kernel/acpi.c | 30 ++++++++++++++++++
>> arch/loongarch/include/asm/acpi.h | 5 ---
>> arch/loongarch/kernel/acpi.c | 9 ++++++
>> arch/riscv/include/asm/acpi.h | 4 ---
>> arch/riscv/kernel/acpi.c | 16 ++++++++++
>> arch/riscv/kernel/acpi_numa.c | 9 ++++--
>> arch/x86/include/asm/cpu.h | 1 -
>> arch/x86/include/asm/smp.h | 1 -
>> arch/x86/kernel/acpi/boot.c | 20 ++++++++++++
>> arch/x86/xen/enlighten_hvm.c | 5 +--
>> drivers/acpi/pptt.c | 50 ++++++++++++++++++++++--------
>> drivers/acpi/riscv/rhct.c | 7 ++++-
>> drivers/pci/tph.c | 16 +++++++---
>> drivers/perf/arm_cspmu/arm_cspmu.c | 6 ++--
>> include/linux/acpi.h | 11 +++++++
>> include/linux/pci-tph.h | 4 +--
>> 18 files changed, 158 insertions(+), 57 deletions(-)
>>
>> --
>
> It doesn't look like anyone has a particular heartburn related to this
> series, so I could apply it in principle, but I'd appreciate some ACKs
> from arch maintainers.
>
> Why don't you resend it with all of the tags collected so far (and
> please add x86@kernel.org to the CC list)?
done for resend v10 which with all the review/ack tag, add add x86@kernel.org to CC list
Thanks
^ permalink raw reply
* [PATCH RESEND v10 6/8] perf: arm_cspmu: Switch to acpi_get_cpu_uid() from get_acpi_id_for_cpu()
From: Chengwen Feng @ 2026-04-01 8:16 UTC (permalink / raw)
To: Bjorn Helgaas, Catalin Marinas, Will Deacon, Rafael J . Wysocki
Cc: Jonathan Corbet, WANG Xuerui, Thomas Gleixner, Dave Hansen,
H . Peter Anvin, Juergen Gross, Boris Ostrovsky, Len Brown,
Sunil V L, Mark Rutland, Jonathan Cameron, Kees Cook, Yanteng Si,
Sean Christopherson, Kai Huang, Tom Lendacky, Thomas Huth,
Thorsten Blum, Kevin Loughlin, Zheyun Shen, Peter Zijlstra,
Pawan Gupta, Xin Li, Ahmed S . Darwish, Sohil Mehta,
Ilkka Koskinen, Robin Murphy, James Clark, Besar Wicaksono, Ma Ke,
Wei Huang, Andy Gospodarek, Somnath Kotur, punit.agrawal,
guohanjun, suzuki.poulose, ryan.roberts, chenl311, masahiroy,
wangyuquan1236, anshuman.khandual, heinrich.schuchardt,
Eric.VanTassell, wangzhou1, wanghuiqiang, liuyonglong,
fengchengwen, linux-pci, linux-doc, linux-kernel,
linux-arm-kernel, loongarch, linux-riscv, xen-devel, linux-acpi,
linux-perf-users, stable, x86
In-Reply-To: <20260401081640.26875-1-fengchengwen@huawei.com>
Update arm_cspmu to use acpi_get_cpu_uid() instead of
get_acpi_id_for_cpu(), aligning with unified ACPI CPU UID interface.
No functional changes are introduced by this switch (valid inputs retain
original behavior).
Cc: stable@vger.kernel.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
---
drivers/perf/arm_cspmu/arm_cspmu.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c
index 34430b68f602..ed72c3d1f796 100644
--- a/drivers/perf/arm_cspmu/arm_cspmu.c
+++ b/drivers/perf/arm_cspmu/arm_cspmu.c
@@ -1107,15 +1107,17 @@ static int arm_cspmu_acpi_get_cpus(struct arm_cspmu *cspmu)
{
struct acpi_apmt_node *apmt_node;
int affinity_flag;
+ u32 cpu_uid;
int cpu;
+ int ret;
apmt_node = arm_cspmu_apmt_node(cspmu->dev);
affinity_flag = apmt_node->flags & ACPI_APMT_FLAGS_AFFINITY;
if (affinity_flag == ACPI_APMT_FLAGS_AFFINITY_PROC) {
for_each_possible_cpu(cpu) {
- if (apmt_node->proc_affinity ==
- get_acpi_id_for_cpu(cpu)) {
+ ret = acpi_get_cpu_uid(cpu, &cpu_uid);
+ if (ret == 0 && apmt_node->proc_affinity == cpu_uid) {
cpumask_set_cpu(cpu, &cspmu->associated_cpus);
break;
}
--
2.17.1
^ permalink raw reply related
* [PATCH RESEND v10 1/8] arm64: acpi: Add acpi_get_cpu_uid() for unified ACPI CPU UID retrieval
From: Chengwen Feng @ 2026-04-01 8:16 UTC (permalink / raw)
To: Bjorn Helgaas, Catalin Marinas, Will Deacon, Rafael J . Wysocki
Cc: Jonathan Corbet, WANG Xuerui, Thomas Gleixner, Dave Hansen,
H . Peter Anvin, Juergen Gross, Boris Ostrovsky, Len Brown,
Sunil V L, Mark Rutland, Jonathan Cameron, Kees Cook, Yanteng Si,
Sean Christopherson, Kai Huang, Tom Lendacky, Thomas Huth,
Thorsten Blum, Kevin Loughlin, Zheyun Shen, Peter Zijlstra,
Pawan Gupta, Xin Li, Ahmed S . Darwish, Sohil Mehta,
Ilkka Koskinen, Robin Murphy, James Clark, Besar Wicaksono, Ma Ke,
Wei Huang, Andy Gospodarek, Somnath Kotur, punit.agrawal,
guohanjun, suzuki.poulose, ryan.roberts, chenl311, masahiroy,
wangyuquan1236, anshuman.khandual, heinrich.schuchardt,
Eric.VanTassell, wangzhou1, wanghuiqiang, liuyonglong,
fengchengwen, linux-pci, linux-doc, linux-kernel,
linux-arm-kernel, loongarch, linux-riscv, xen-devel, linux-acpi,
linux-perf-users, stable, x86
In-Reply-To: <20260401081640.26875-1-fengchengwen@huawei.com>
As a step towards unifying the interface for retrieving ACPI CPU UID
across architectures, introduce a new function acpi_get_cpu_uid() for
arm64. While at it, add input validation to make the code more robust.
Reimplement get_cpu_for_acpi_id() based on acpi_get_cpu_uid() for
consistency, and move its implementation next to the new function for
code coherence.
Cc: stable@vger.kernel.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/include/asm/acpi.h | 14 ++------------
arch/arm64/kernel/acpi.c | 30 ++++++++++++++++++++++++++++++
2 files changed, 32 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index c07a58b96329..2219a3301e72 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -118,18 +118,8 @@ static inline u32 get_acpi_id_for_cpu(unsigned int cpu)
{
return acpi_cpu_get_madt_gicc(cpu)->uid;
}
-
-static inline int get_cpu_for_acpi_id(u32 uid)
-{
- int cpu;
-
- for (cpu = 0; cpu < nr_cpu_ids; cpu++)
- if (acpi_cpu_get_madt_gicc(cpu) &&
- uid == get_acpi_id_for_cpu(cpu))
- return cpu;
-
- return -EINVAL;
-}
+int acpi_get_cpu_uid(unsigned int cpu, u32 *uid);
+int get_cpu_for_acpi_id(u32 uid);
static inline void arch_fix_phys_package_id(int num, u32 slot) { }
void __init acpi_init_cpus(void);
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index af90128cfed5..24b9d934be54 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -458,3 +458,33 @@ int acpi_unmap_cpu(int cpu)
}
EXPORT_SYMBOL(acpi_unmap_cpu);
#endif /* CONFIG_ACPI_HOTPLUG_CPU */
+
+int acpi_get_cpu_uid(unsigned int cpu, u32 *uid)
+{
+ struct acpi_madt_generic_interrupt *gicc;
+
+ if (cpu >= nr_cpu_ids)
+ return -EINVAL;
+
+ gicc = acpi_cpu_get_madt_gicc(cpu);
+ if (!gicc)
+ return -ENODEV;
+
+ *uid = gicc->uid;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(acpi_get_cpu_uid);
+
+int get_cpu_for_acpi_id(u32 uid)
+{
+ u32 cpu_uid;
+ int ret;
+
+ for (int cpu = 0; cpu < nr_cpu_ids; cpu++) {
+ ret = acpi_get_cpu_uid(cpu, &cpu_uid);
+ if (ret == 0 && uid == cpu_uid)
+ return cpu;
+ }
+
+ return -EINVAL;
+}
--
2.17.1
^ permalink raw reply related
* [PATCH RESEND v10 8/8] PCI/TPH: Pass ACPI Processor UID to Cache Locality _DSM
From: Chengwen Feng @ 2026-04-01 8:16 UTC (permalink / raw)
To: Bjorn Helgaas, Catalin Marinas, Will Deacon, Rafael J . Wysocki
Cc: Jonathan Corbet, WANG Xuerui, Thomas Gleixner, Dave Hansen,
H . Peter Anvin, Juergen Gross, Boris Ostrovsky, Len Brown,
Sunil V L, Mark Rutland, Jonathan Cameron, Kees Cook, Yanteng Si,
Sean Christopherson, Kai Huang, Tom Lendacky, Thomas Huth,
Thorsten Blum, Kevin Loughlin, Zheyun Shen, Peter Zijlstra,
Pawan Gupta, Xin Li, Ahmed S . Darwish, Sohil Mehta,
Ilkka Koskinen, Robin Murphy, James Clark, Besar Wicaksono, Ma Ke,
Wei Huang, Andy Gospodarek, Somnath Kotur, punit.agrawal,
guohanjun, suzuki.poulose, ryan.roberts, chenl311, masahiroy,
wangyuquan1236, anshuman.khandual, heinrich.schuchardt,
Eric.VanTassell, wangzhou1, wanghuiqiang, liuyonglong,
fengchengwen, linux-pci, linux-doc, linux-kernel,
linux-arm-kernel, loongarch, linux-riscv, xen-devel, linux-acpi,
linux-perf-users, stable, x86
In-Reply-To: <20260401081640.26875-1-fengchengwen@huawei.com>
pcie_tph_get_cpu_st() uses the Query Cache Locality Features _DSM [1]
to retrieve the TPH Steering Tag for memory associated with the CPU
identified by its "cpu_uid" parameter, a Linux logical CPU ID.
The _DSM requires an ACPI Processor UID, which pcie_tph_get_cpu_st()
previously assumed was the same as the Linux logical CPU ID. This is
true on x86 but not on arm64, so pcie_tph_get_cpu_st() returned the
wrong Steering Tag, resulting in incorrect TPH functionality on arm64.
Convert the Linux logical CPU ID to the ACPI Processor UID with
acpi_get_cpu_uid() before passing it to the _DSM. Additionally, rename
the pcie_tph_get_cpu_st() parameter from "cpu_uid" to "cpu" to reflect
that it represents a logical CPU ID (not an ACPI Processor UID).
[1] According to ECN_TPH-ST_Revision_20200924
(https://members.pcisig.com/wg/PCI-SIG/document/15470), the input
is defined as: "If the target is a processor, then this field
represents the ACPI Processor UID of the processor as specified in
the MADT. If the target is a processor container, then this field
represents the ACPI Processor UID of the processor container as
specified in the PPTT."
Fixes: d2e8a34876ce ("PCI/TPH: Add Steering Tag support")
Cc: stable@vger.kernel.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
---
Documentation/PCI/tph.rst | 4 ++--
drivers/pci/tph.c | 16 +++++++++++-----
include/linux/pci-tph.h | 4 ++--
3 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/Documentation/PCI/tph.rst b/Documentation/PCI/tph.rst
index e8993be64fd6..b6cf22b9bd90 100644
--- a/Documentation/PCI/tph.rst
+++ b/Documentation/PCI/tph.rst
@@ -79,10 +79,10 @@ To retrieve a Steering Tag for a target memory associated with a specific
CPU, use the following function::
int pcie_tph_get_cpu_st(struct pci_dev *pdev, enum tph_mem_type type,
- unsigned int cpu_uid, u16 *tag);
+ unsigned int cpu, u16 *tag);
The `type` argument is used to specify the memory type, either volatile
-or persistent, of the target memory. The `cpu_uid` argument specifies the
+or persistent, of the target memory. The `cpu` argument specifies the
CPU where the memory is associated to.
After the ST value is retrieved, the device driver can use the following
diff --git a/drivers/pci/tph.c b/drivers/pci/tph.c
index ca4f97be7538..b67c9ad14bda 100644
--- a/drivers/pci/tph.c
+++ b/drivers/pci/tph.c
@@ -236,21 +236,27 @@ static int write_tag_to_st_table(struct pci_dev *pdev, int index, u16 tag)
* with a specific CPU
* @pdev: PCI device
* @mem_type: target memory type (volatile or persistent RAM)
- * @cpu_uid: associated CPU id
+ * @cpu: associated CPU id
* @tag: Steering Tag to be returned
*
* Return the Steering Tag for a target memory that is associated with a
- * specific CPU as indicated by cpu_uid.
+ * specific CPU as indicated by cpu.
*
* Return: 0 if success, otherwise negative value (-errno)
*/
int pcie_tph_get_cpu_st(struct pci_dev *pdev, enum tph_mem_type mem_type,
- unsigned int cpu_uid, u16 *tag)
+ unsigned int cpu, u16 *tag)
{
#ifdef CONFIG_ACPI
struct pci_dev *rp;
acpi_handle rp_acpi_handle;
union st_info info;
+ u32 cpu_uid;
+ int ret;
+
+ ret = acpi_get_cpu_uid(cpu, &cpu_uid);
+ if (ret != 0)
+ return ret;
rp = pcie_find_root_port(pdev);
if (!rp || !rp->bus || !rp->bus->bridge)
@@ -265,9 +271,9 @@ int pcie_tph_get_cpu_st(struct pci_dev *pdev, enum tph_mem_type mem_type,
*tag = tph_extract_tag(mem_type, pdev->tph_req_type, &info);
- pci_dbg(pdev, "get steering tag: mem_type=%s, cpu_uid=%d, tag=%#04x\n",
+ pci_dbg(pdev, "get steering tag: mem_type=%s, cpu=%d, tag=%#04x\n",
(mem_type == TPH_MEM_TYPE_VM) ? "volatile" : "persistent",
- cpu_uid, *tag);
+ cpu, *tag);
return 0;
#else
diff --git a/include/linux/pci-tph.h b/include/linux/pci-tph.h
index ba28140ce670..be68cd17f2f8 100644
--- a/include/linux/pci-tph.h
+++ b/include/linux/pci-tph.h
@@ -25,7 +25,7 @@ int pcie_tph_set_st_entry(struct pci_dev *pdev,
unsigned int index, u16 tag);
int pcie_tph_get_cpu_st(struct pci_dev *dev,
enum tph_mem_type mem_type,
- unsigned int cpu_uid, u16 *tag);
+ unsigned int cpu, u16 *tag);
void pcie_disable_tph(struct pci_dev *pdev);
int pcie_enable_tph(struct pci_dev *pdev, int mode);
u16 pcie_tph_get_st_table_size(struct pci_dev *pdev);
@@ -36,7 +36,7 @@ static inline int pcie_tph_set_st_entry(struct pci_dev *pdev,
{ return -EINVAL; }
static inline int pcie_tph_get_cpu_st(struct pci_dev *dev,
enum tph_mem_type mem_type,
- unsigned int cpu_uid, u16 *tag)
+ unsigned int cpu, u16 *tag)
{ return -EINVAL; }
static inline void pcie_disable_tph(struct pci_dev *pdev) { }
static inline int pcie_enable_tph(struct pci_dev *pdev, int mode)
--
2.17.1
^ permalink raw reply related
* [PATCH RESEND v10 3/8] RISC-V: ACPI: Add acpi_get_cpu_uid() for unified ACPI CPU UID retrieval
From: Chengwen Feng @ 2026-04-01 8:16 UTC (permalink / raw)
To: Bjorn Helgaas, Catalin Marinas, Will Deacon, Rafael J . Wysocki
Cc: Jonathan Corbet, WANG Xuerui, Thomas Gleixner, Dave Hansen,
H . Peter Anvin, Juergen Gross, Boris Ostrovsky, Len Brown,
Sunil V L, Mark Rutland, Jonathan Cameron, Kees Cook, Yanteng Si,
Sean Christopherson, Kai Huang, Tom Lendacky, Thomas Huth,
Thorsten Blum, Kevin Loughlin, Zheyun Shen, Peter Zijlstra,
Pawan Gupta, Xin Li, Ahmed S . Darwish, Sohil Mehta,
Ilkka Koskinen, Robin Murphy, James Clark, Besar Wicaksono, Ma Ke,
Wei Huang, Andy Gospodarek, Somnath Kotur, punit.agrawal,
guohanjun, suzuki.poulose, ryan.roberts, chenl311, masahiroy,
wangyuquan1236, anshuman.khandual, heinrich.schuchardt,
Eric.VanTassell, wangzhou1, wanghuiqiang, liuyonglong,
fengchengwen, linux-pci, linux-doc, linux-kernel,
linux-arm-kernel, loongarch, linux-riscv, xen-devel, linux-acpi,
linux-perf-users, stable, x86
In-Reply-To: <20260401081640.26875-1-fengchengwen@huawei.com>
As a step towards unifying the interface for retrieving ACPI CPU UID
across architectures, introduce a new function acpi_get_cpu_uid() for
riscv. While at it, add input validation to make the code more robust.
And also update acpi_numa.c and rhct.c to use the new interface instead
of the legacy get_acpi_id_for_cpu().
Cc: stable@vger.kernel.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
---
arch/riscv/include/asm/acpi.h | 1 +
arch/riscv/kernel/acpi.c | 16 ++++++++++++++++
arch/riscv/kernel/acpi_numa.c | 9 ++++++---
drivers/acpi/riscv/rhct.c | 7 ++++++-
4 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/arch/riscv/include/asm/acpi.h b/arch/riscv/include/asm/acpi.h
index 6e13695120bc..f3520cc85af3 100644
--- a/arch/riscv/include/asm/acpi.h
+++ b/arch/riscv/include/asm/acpi.h
@@ -65,6 +65,7 @@ static inline u32 get_acpi_id_for_cpu(int cpu)
{
return acpi_cpu_get_madt_rintc(cpu)->uid;
}
+int acpi_get_cpu_uid(unsigned int cpu, u32 *uid);
int acpi_get_riscv_isa(struct acpi_table_header *table,
unsigned int cpu, const char **isa);
diff --git a/arch/riscv/kernel/acpi.c b/arch/riscv/kernel/acpi.c
index 71698ee11621..322ea92aa39f 100644
--- a/arch/riscv/kernel/acpi.c
+++ b/arch/riscv/kernel/acpi.c
@@ -337,3 +337,19 @@ int raw_pci_write(unsigned int domain, unsigned int bus,
}
#endif /* CONFIG_PCI */
+
+int acpi_get_cpu_uid(unsigned int cpu, u32 *uid)
+{
+ struct acpi_madt_rintc *rintc;
+
+ if (cpu >= nr_cpu_ids)
+ return -EINVAL;
+
+ rintc = acpi_cpu_get_madt_rintc(cpu);
+ if (!rintc)
+ return -ENODEV;
+
+ *uid = rintc->uid;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(acpi_get_cpu_uid);
diff --git a/arch/riscv/kernel/acpi_numa.c b/arch/riscv/kernel/acpi_numa.c
index 130769e3a99c..6a2d4289f806 100644
--- a/arch/riscv/kernel/acpi_numa.c
+++ b/arch/riscv/kernel/acpi_numa.c
@@ -37,11 +37,14 @@ static int __init acpi_numa_get_nid(unsigned int cpu)
static inline int get_cpu_for_acpi_id(u32 uid)
{
- int cpu;
+ u32 cpu_uid;
+ int ret;
- for (cpu = 0; cpu < nr_cpu_ids; cpu++)
- if (uid == get_acpi_id_for_cpu(cpu))
+ for (int cpu = 0; cpu < nr_cpu_ids; cpu++) {
+ ret = acpi_get_cpu_uid(cpu, &cpu_uid);
+ if (ret == 0 && uid == cpu_uid)
return cpu;
+ }
return -EINVAL;
}
diff --git a/drivers/acpi/riscv/rhct.c b/drivers/acpi/riscv/rhct.c
index caa2c16e1697..8f3f38c64a88 100644
--- a/drivers/acpi/riscv/rhct.c
+++ b/drivers/acpi/riscv/rhct.c
@@ -44,10 +44,15 @@ int acpi_get_riscv_isa(struct acpi_table_header *table, unsigned int cpu, const
struct acpi_rhct_isa_string *isa_node;
struct acpi_table_rhct *rhct;
u32 *hart_info_node_offset;
- u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu);
+ u32 acpi_cpu_id;
+ int ret;
BUG_ON(acpi_disabled);
+ ret = acpi_get_cpu_uid(cpu, &acpi_cpu_id);
+ if (ret != 0)
+ return ret;
+
if (!table) {
rhct = acpi_get_rhct();
if (!rhct)
--
2.17.1
^ permalink raw reply related
* [PATCH RESEND v10 7/8] ACPI: PPTT: Use acpi_get_cpu_uid() and remove get_acpi_id_for_cpu()
From: Chengwen Feng @ 2026-04-01 8:16 UTC (permalink / raw)
To: Bjorn Helgaas, Catalin Marinas, Will Deacon, Rafael J . Wysocki
Cc: Jonathan Corbet, WANG Xuerui, Thomas Gleixner, Dave Hansen,
H . Peter Anvin, Juergen Gross, Boris Ostrovsky, Len Brown,
Sunil V L, Mark Rutland, Jonathan Cameron, Kees Cook, Yanteng Si,
Sean Christopherson, Kai Huang, Tom Lendacky, Thomas Huth,
Thorsten Blum, Kevin Loughlin, Zheyun Shen, Peter Zijlstra,
Pawan Gupta, Xin Li, Ahmed S . Darwish, Sohil Mehta,
Ilkka Koskinen, Robin Murphy, James Clark, Besar Wicaksono, Ma Ke,
Wei Huang, Andy Gospodarek, Somnath Kotur, punit.agrawal,
guohanjun, suzuki.poulose, ryan.roberts, chenl311, masahiroy,
wangyuquan1236, anshuman.khandual, heinrich.schuchardt,
Eric.VanTassell, wangzhou1, wanghuiqiang, liuyonglong,
fengchengwen, linux-pci, linux-doc, linux-kernel,
linux-arm-kernel, loongarch, linux-riscv, xen-devel, linux-acpi,
linux-perf-users, stable, x86
In-Reply-To: <20260401081640.26875-1-fengchengwen@huawei.com>
Update acpi/pptt.c to use acpi_get_cpu_uid() and remove unused
get_acpi_id_for_cpu() from arm64/loongarch/riscv, completing PPTT's
migration to the unified ACPI CPU UID interface
Cc: stable@vger.kernel.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
---
arch/arm64/include/asm/acpi.h | 4 ---
arch/loongarch/include/asm/acpi.h | 5 ----
arch/riscv/include/asm/acpi.h | 4 ---
drivers/acpi/pptt.c | 50 +++++++++++++++++++++++--------
4 files changed, 37 insertions(+), 26 deletions(-)
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index bdb0ecf95b5c..8a54ca6ba602 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -114,10 +114,6 @@ static inline bool acpi_has_cpu_in_madt(void)
}
struct acpi_madt_generic_interrupt *acpi_cpu_get_madt_gicc(int cpu);
-static inline u32 get_acpi_id_for_cpu(unsigned int cpu)
-{
- return acpi_cpu_get_madt_gicc(cpu)->uid;
-}
int get_cpu_for_acpi_id(u32 uid);
static inline void arch_fix_phys_package_id(int num, u32 slot) { }
diff --git a/arch/loongarch/include/asm/acpi.h b/arch/loongarch/include/asm/acpi.h
index 7376840fa9f7..eda9d4d0a493 100644
--- a/arch/loongarch/include/asm/acpi.h
+++ b/arch/loongarch/include/asm/acpi.h
@@ -40,11 +40,6 @@ extern struct acpi_madt_core_pic acpi_core_pic[MAX_CORE_PIC];
extern int __init parse_acpi_topology(void);
-static inline u32 get_acpi_id_for_cpu(unsigned int cpu)
-{
- return acpi_core_pic[cpu_logical_map(cpu)].processor_id;
-}
-
#endif /* !CONFIG_ACPI */
#define ACPI_TABLE_UPGRADE_MAX_PHYS ARCH_LOW_ADDRESS_LIMIT
diff --git a/arch/riscv/include/asm/acpi.h b/arch/riscv/include/asm/acpi.h
index 6e13695120bc..26ab37c171bc 100644
--- a/arch/riscv/include/asm/acpi.h
+++ b/arch/riscv/include/asm/acpi.h
@@ -61,10 +61,6 @@ static inline void arch_fix_phys_package_id(int num, u32 slot) { }
void acpi_init_rintc_map(void);
struct acpi_madt_rintc *acpi_cpu_get_madt_rintc(int cpu);
-static inline u32 get_acpi_id_for_cpu(int cpu)
-{
- return acpi_cpu_get_madt_rintc(cpu)->uid;
-}
int acpi_get_riscv_isa(struct acpi_table_header *table,
unsigned int cpu, const char **isa);
diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
index de5f8c018333..7bd5bc1f225a 100644
--- a/drivers/acpi/pptt.c
+++ b/drivers/acpi/pptt.c
@@ -459,11 +459,14 @@ static void cache_setup_acpi_cpu(struct acpi_table_header *table,
{
struct acpi_pptt_cache *found_cache;
struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
- u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu);
+ u32 acpi_cpu_id;
struct cacheinfo *this_leaf;
unsigned int index = 0;
struct acpi_pptt_processor *cpu_node = NULL;
+ if (acpi_get_cpu_uid(cpu, &acpi_cpu_id) != 0)
+ return;
+
while (index < get_cpu_cacheinfo(cpu)->num_leaves) {
this_leaf = this_cpu_ci->info_list + index;
found_cache = acpi_find_cache_node(table, acpi_cpu_id,
@@ -546,7 +549,10 @@ static int topology_get_acpi_cpu_tag(struct acpi_table_header *table,
unsigned int cpu, int level, int flag)
{
struct acpi_pptt_processor *cpu_node;
- u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu);
+ u32 acpi_cpu_id;
+
+ if (acpi_get_cpu_uid(cpu, &acpi_cpu_id) != 0)
+ return -ENOENT;
cpu_node = acpi_find_processor_node(table, acpi_cpu_id);
if (cpu_node) {
@@ -614,18 +620,22 @@ static int find_acpi_cpu_topology_tag(unsigned int cpu, int level, int flag)
*
* Check the node representing a CPU for a given flag.
*
- * Return: -ENOENT if the PPTT doesn't exist, the CPU cannot be found or
- * the table revision isn't new enough.
+ * Return: -ENOENT if can't get CPU's ACPI Processor UID, the PPTT doesn't
+ * exist, the CPU cannot be found or the table revision isn't new
+ * enough.
* 1, any passed flag set
* 0, flag unset
*/
static int check_acpi_cpu_flag(unsigned int cpu, int rev, u32 flag)
{
struct acpi_table_header *table;
- u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu);
+ u32 acpi_cpu_id;
struct acpi_pptt_processor *cpu_node = NULL;
int ret = -ENOENT;
+ if (acpi_get_cpu_uid(cpu, &acpi_cpu_id) != 0)
+ return -ENOENT;
+
table = acpi_get_pptt();
if (!table)
return -ENOENT;
@@ -651,7 +661,8 @@ static int check_acpi_cpu_flag(unsigned int cpu, int rev, u32 flag)
* in the PPTT. Errors caused by lack of a PPTT table, or otherwise, return 0
* indicating we didn't find any cache levels.
*
- * Return: -ENOENT if no PPTT table or no PPTT processor struct found.
+ * Return: -ENOENT if no PPTT table, can't get CPU's ACPI Process UID or no PPTT
+ * processor struct found.
* 0 on success.
*/
int acpi_get_cache_info(unsigned int cpu, unsigned int *levels,
@@ -671,7 +682,9 @@ int acpi_get_cache_info(unsigned int cpu, unsigned int *levels,
pr_debug("Cache Setup: find cache levels for CPU=%d\n", cpu);
- acpi_cpu_id = get_acpi_id_for_cpu(cpu);
+ if (acpi_get_cpu_uid(cpu, &acpi_cpu_id))
+ return -ENOENT;
+
cpu_node = acpi_find_processor_node(table, acpi_cpu_id);
if (!cpu_node)
return -ENOENT;
@@ -780,8 +793,9 @@ int find_acpi_cpu_topology_package(unsigned int cpu)
* It may not exist in single CPU systems. In simple multi-CPU systems,
* it may be equal to the package topology level.
*
- * Return: -ENOENT if the PPTT doesn't exist, the CPU cannot be found
- * or there is no toplogy level above the CPU..
+ * Return: -ENOENT if the PPTT doesn't exist, can't get CPU's ACPI
+ * Processor UID, the CPU cannot be found or there is no toplogy level
+ * above the CPU.
* Otherwise returns a value which represents the package for this CPU.
*/
@@ -797,7 +811,9 @@ int find_acpi_cpu_topology_cluster(unsigned int cpu)
if (!table)
return -ENOENT;
- acpi_cpu_id = get_acpi_id_for_cpu(cpu);
+ if (acpi_get_cpu_uid(cpu, &acpi_cpu_id) != 0)
+ return -ENOENT;
+
cpu_node = acpi_find_processor_node(table, acpi_cpu_id);
if (!cpu_node || !cpu_node->parent)
return -ENOENT;
@@ -872,7 +888,9 @@ static void acpi_pptt_get_child_cpus(struct acpi_table_header *table_hdr,
cpumask_clear(cpus);
for_each_possible_cpu(cpu) {
- acpi_id = get_acpi_id_for_cpu(cpu);
+ if (acpi_get_cpu_uid(cpu, &acpi_id) != 0)
+ continue;
+
cpu_node = acpi_find_processor_node(table_hdr, acpi_id);
while (cpu_node) {
@@ -966,10 +984,13 @@ int find_acpi_cache_level_from_id(u32 cache_id)
for_each_possible_cpu(cpu) {
bool empty;
int level = 1;
- u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu);
+ u32 acpi_cpu_id;
struct acpi_pptt_cache *cache;
struct acpi_pptt_processor *cpu_node;
+ if (acpi_get_cpu_uid(cpu, &acpi_cpu_id) != 0)
+ continue;
+
cpu_node = acpi_find_processor_node(table, acpi_cpu_id);
if (!cpu_node)
continue;
@@ -1030,10 +1051,13 @@ int acpi_pptt_get_cpumask_from_cache_id(u32 cache_id, cpumask_t *cpus)
for_each_possible_cpu(cpu) {
bool empty;
int level = 1;
- u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu);
+ u32 acpi_cpu_id;
struct acpi_pptt_cache *cache;
struct acpi_pptt_processor *cpu_node;
+ if (acpi_get_cpu_uid(cpu, &acpi_cpu_id) != 0)
+ continue;
+
cpu_node = acpi_find_processor_node(table, acpi_cpu_id);
if (!cpu_node)
continue;
--
2.17.1
^ permalink raw reply related
* [PATCH RESEND v10 5/8] ACPI: Centralize acpi_get_cpu_uid() declaration in include/linux/acpi.h
From: Chengwen Feng @ 2026-04-01 8:16 UTC (permalink / raw)
To: Bjorn Helgaas, Catalin Marinas, Will Deacon, Rafael J . Wysocki
Cc: Jonathan Corbet, WANG Xuerui, Thomas Gleixner, Dave Hansen,
H . Peter Anvin, Juergen Gross, Boris Ostrovsky, Len Brown,
Sunil V L, Mark Rutland, Jonathan Cameron, Kees Cook, Yanteng Si,
Sean Christopherson, Kai Huang, Tom Lendacky, Thomas Huth,
Thorsten Blum, Kevin Loughlin, Zheyun Shen, Peter Zijlstra,
Pawan Gupta, Xin Li, Ahmed S . Darwish, Sohil Mehta,
Ilkka Koskinen, Robin Murphy, James Clark, Besar Wicaksono, Ma Ke,
Wei Huang, Andy Gospodarek, Somnath Kotur, punit.agrawal,
guohanjun, suzuki.poulose, ryan.roberts, chenl311, masahiroy,
wangyuquan1236, anshuman.khandual, heinrich.schuchardt,
Eric.VanTassell, wangzhou1, wanghuiqiang, liuyonglong,
fengchengwen, linux-pci, linux-doc, linux-kernel,
linux-arm-kernel, loongarch, linux-riscv, xen-devel, linux-acpi,
linux-perf-users, stable, x86
In-Reply-To: <20260401081640.26875-1-fengchengwen@huawei.com>
Centralize acpi_get_cpu_uid() in include/linux/acpi.h (global scope) and
remove arch-specific declarations from arm64/loongarch/riscv/x86
asm/acpi.h. This unifies the interface across architectures and
simplifies maintenance by eliminating duplicate prototypes.
Cc: stable@vger.kernel.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
---
arch/arm64/include/asm/acpi.h | 1 -
arch/loongarch/include/asm/acpi.h | 1 -
arch/riscv/include/asm/acpi.h | 1 -
arch/x86/include/asm/acpi.h | 2 --
include/linux/acpi.h | 11 +++++++++++
5 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 2219a3301e72..bdb0ecf95b5c 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -118,7 +118,6 @@ static inline u32 get_acpi_id_for_cpu(unsigned int cpu)
{
return acpi_cpu_get_madt_gicc(cpu)->uid;
}
-int acpi_get_cpu_uid(unsigned int cpu, u32 *uid);
int get_cpu_for_acpi_id(u32 uid);
static inline void arch_fix_phys_package_id(int num, u32 slot) { }
diff --git a/arch/loongarch/include/asm/acpi.h b/arch/loongarch/include/asm/acpi.h
index 8bb101b4557e..7376840fa9f7 100644
--- a/arch/loongarch/include/asm/acpi.h
+++ b/arch/loongarch/include/asm/acpi.h
@@ -44,7 +44,6 @@ static inline u32 get_acpi_id_for_cpu(unsigned int cpu)
{
return acpi_core_pic[cpu_logical_map(cpu)].processor_id;
}
-int acpi_get_cpu_uid(unsigned int cpu, u32 *uid);
#endif /* !CONFIG_ACPI */
diff --git a/arch/riscv/include/asm/acpi.h b/arch/riscv/include/asm/acpi.h
index f3520cc85af3..6e13695120bc 100644
--- a/arch/riscv/include/asm/acpi.h
+++ b/arch/riscv/include/asm/acpi.h
@@ -65,7 +65,6 @@ static inline u32 get_acpi_id_for_cpu(int cpu)
{
return acpi_cpu_get_madt_rintc(cpu)->uid;
}
-int acpi_get_cpu_uid(unsigned int cpu, u32 *uid);
int acpi_get_riscv_isa(struct acpi_table_header *table,
unsigned int cpu, const char **isa);
diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
index 92b5c27c4fea..a03aa6f999d1 100644
--- a/arch/x86/include/asm/acpi.h
+++ b/arch/x86/include/asm/acpi.h
@@ -157,8 +157,6 @@ static inline bool acpi_has_cpu_in_madt(void)
return !!acpi_lapic;
}
-int acpi_get_cpu_uid(unsigned int cpu, u32 *uid);
-
#define ACPI_HAVE_ARCH_SET_ROOT_POINTER
static __always_inline void acpi_arch_set_root_pointer(u64 addr)
{
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 4d2f0bed7a06..74a73f0e5944 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -324,6 +324,17 @@ int acpi_unmap_cpu(int cpu);
acpi_handle acpi_get_processor_handle(int cpu);
+/**
+ * acpi_get_cpu_uid() - Get ACPI Processor UID of from MADT table
+ * @cpu: Logical CPU number (0-based)
+ * @uid: Pointer to store ACPI Processor UID
+ *
+ * Return: 0 on success (ACPI Processor ID stored in *uid);
+ * -EINVAL if CPU number is invalid or out of range;
+ * -ENODEV if ACPI Processor UID for the CPU is not found.
+ */
+int acpi_get_cpu_uid(unsigned int cpu, u32 *uid);
+
#ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
int acpi_get_ioapic_id(acpi_handle handle, u32 gsi_base, u64 *phys_addr);
#endif
--
2.17.1
^ permalink raw reply related
* [PATCH RESEND v10 0/8] ACPI: Unify CPU UID interface and fix ARM64 TPH steer-tag issue
From: Chengwen Feng @ 2026-04-01 8:16 UTC (permalink / raw)
To: Bjorn Helgaas, Catalin Marinas, Will Deacon, Rafael J . Wysocki
Cc: Jonathan Corbet, WANG Xuerui, Thomas Gleixner, Dave Hansen,
H . Peter Anvin, Juergen Gross, Boris Ostrovsky, Len Brown,
Sunil V L, Mark Rutland, Jonathan Cameron, Kees Cook, Yanteng Si,
Sean Christopherson, Kai Huang, Tom Lendacky, Thomas Huth,
Thorsten Blum, Kevin Loughlin, Zheyun Shen, Peter Zijlstra,
Pawan Gupta, Xin Li, Ahmed S . Darwish, Sohil Mehta,
Ilkka Koskinen, Robin Murphy, James Clark, Besar Wicaksono, Ma Ke,
Wei Huang, Andy Gospodarek, Somnath Kotur, punit.agrawal,
guohanjun, suzuki.poulose, ryan.roberts, chenl311, masahiroy,
wangyuquan1236, anshuman.khandual, heinrich.schuchardt,
Eric.VanTassell, wangzhou1, wanghuiqiang, liuyonglong,
fengchengwen, linux-pci, linux-doc, linux-kernel,
linux-arm-kernel, loongarch, linux-riscv, xen-devel, linux-acpi,
linux-perf-users, stable, x86
This patchset unifies ACPI Processor UID retrieval across
arm64/loongarch/riscv/x86 via acpi_get_cpu_uid() (with input validation)
and fixes ARM64 CPU steer-tag retrieval failure in PCI/TPH:
1-4: Add acpi_get_cpu_uid() for arm64/loongarch/riscv/x86 (update
respective users)
5: Centralize acpi_get_cpu_uid() declaration in include/linux/acpi.h
6: Clean up perf/arm_cspmu
7: Clean up ACPI/PPTT and remove unused get_acpi_id_for_cpu()
8: Pass ACPI Processor UID to Cache Locality _DSM
The interface refactor ensures consistent CPU UID retrieval across
architectures (no functional changes for valid inputs) and provides the
unified interface required for the ARM64 TPH fix
---
Changes in v10-resend:
- Add Catalin's ack-by for arm64 commit
- Add CC to x86@kernel.org
Changes in v10:
- Refine commit header&log according to Punit's and Bjorn's review
- Split perf/arm_cspmu as a separate commit which address Punit's
review
Changes in v9:
- Address Bjorn's review: split commits to each platform so that make
them easy to review
Changes in v8:
- Moving arm64's get_cpu_for_acpi_id() to kernel/acpi.c which address
Jeremy's review
Chengwen Feng (8):
arm64: acpi: Add acpi_get_cpu_uid() for unified ACPI CPU UID retrieval
LoongArch: Add acpi_get_cpu_uid() for unified ACPI CPU UID retrieval
RISC-V: ACPI: Add acpi_get_cpu_uid() for unified ACPI CPU UID
retrieval
x86/acpi: Add acpi_get_cpu_uid() for unified ACPI CPU UID retrieval
ACPI: Centralize acpi_get_cpu_uid() declaration in
include/linux/acpi.h
perf: arm_cspmu: Switch to acpi_get_cpu_uid() from
get_acpi_id_for_cpu()
ACPI: PPTT: Use acpi_get_cpu_uid() and remove get_acpi_id_for_cpu()
PCI/TPH: Pass ACPI Processor UID to Cache Locality _DSM
Documentation/PCI/tph.rst | 4 +--
arch/arm64/include/asm/acpi.h | 17 +---------
arch/arm64/kernel/acpi.c | 30 ++++++++++++++++++
arch/loongarch/include/asm/acpi.h | 5 ---
arch/loongarch/kernel/acpi.c | 9 ++++++
arch/riscv/include/asm/acpi.h | 4 ---
arch/riscv/kernel/acpi.c | 16 ++++++++++
arch/riscv/kernel/acpi_numa.c | 9 ++++--
arch/x86/include/asm/cpu.h | 1 -
arch/x86/include/asm/smp.h | 1 -
arch/x86/kernel/acpi/boot.c | 20 ++++++++++++
arch/x86/xen/enlighten_hvm.c | 5 +--
drivers/acpi/pptt.c | 50 ++++++++++++++++++++++--------
drivers/acpi/riscv/rhct.c | 7 ++++-
drivers/pci/tph.c | 16 +++++++---
drivers/perf/arm_cspmu/arm_cspmu.c | 6 ++--
include/linux/acpi.h | 11 +++++++
include/linux/pci-tph.h | 4 +--
18 files changed, 158 insertions(+), 57 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH RESEND v10 4/8] x86/acpi: Add acpi_get_cpu_uid() for unified ACPI CPU UID retrieval
From: Chengwen Feng @ 2026-04-01 8:16 UTC (permalink / raw)
To: Bjorn Helgaas, Catalin Marinas, Will Deacon, Rafael J . Wysocki
Cc: Jonathan Corbet, WANG Xuerui, Thomas Gleixner, Dave Hansen,
H . Peter Anvin, Juergen Gross, Boris Ostrovsky, Len Brown,
Sunil V L, Mark Rutland, Jonathan Cameron, Kees Cook, Yanteng Si,
Sean Christopherson, Kai Huang, Tom Lendacky, Thomas Huth,
Thorsten Blum, Kevin Loughlin, Zheyun Shen, Peter Zijlstra,
Pawan Gupta, Xin Li, Ahmed S . Darwish, Sohil Mehta,
Ilkka Koskinen, Robin Murphy, James Clark, Besar Wicaksono, Ma Ke,
Wei Huang, Andy Gospodarek, Somnath Kotur, punit.agrawal,
guohanjun, suzuki.poulose, ryan.roberts, chenl311, masahiroy,
wangyuquan1236, anshuman.khandual, heinrich.schuchardt,
Eric.VanTassell, wangzhou1, wanghuiqiang, liuyonglong,
fengchengwen, linux-pci, linux-doc, linux-kernel,
linux-arm-kernel, loongarch, linux-riscv, xen-devel, linux-acpi,
linux-perf-users, stable, x86
In-Reply-To: <20260401081640.26875-1-fengchengwen@huawei.com>
As a step towards unifying the interface for retrieving ACPI CPU UID
across architectures, introduce a new function acpi_get_cpu_uid() for
x86. While at it, add input validation to make the code more robust.
Update Xen-related code to use acpi_get_cpu_uid() instead of the legacy
cpu_acpi_id() function, and remove the now-unused cpu_acpi_id() to clean
up redundant code.
Cc: stable@vger.kernel.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
---
arch/x86/include/asm/acpi.h | 2 ++
arch/x86/include/asm/cpu.h | 1 -
arch/x86/include/asm/smp.h | 1 -
arch/x86/kernel/acpi/boot.c | 20 ++++++++++++++++++++
arch/x86/xen/enlighten_hvm.c | 5 +++--
5 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
index a03aa6f999d1..92b5c27c4fea 100644
--- a/arch/x86/include/asm/acpi.h
+++ b/arch/x86/include/asm/acpi.h
@@ -157,6 +157,8 @@ static inline bool acpi_has_cpu_in_madt(void)
return !!acpi_lapic;
}
+int acpi_get_cpu_uid(unsigned int cpu, u32 *uid);
+
#define ACPI_HAVE_ARCH_SET_ROOT_POINTER
static __always_inline void acpi_arch_set_root_pointer(u64 addr)
{
diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h
index ad235dda1ded..57a0786dfd75 100644
--- a/arch/x86/include/asm/cpu.h
+++ b/arch/x86/include/asm/cpu.h
@@ -11,7 +11,6 @@
#ifndef CONFIG_SMP
#define cpu_physical_id(cpu) boot_cpu_physical_apicid
-#define cpu_acpi_id(cpu) 0
#endif /* CONFIG_SMP */
#ifdef CONFIG_HOTPLUG_CPU
diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h
index 84951572ab81..05d1d479b4cf 100644
--- a/arch/x86/include/asm/smp.h
+++ b/arch/x86/include/asm/smp.h
@@ -130,7 +130,6 @@ __visible void smp_call_function_interrupt(struct pt_regs *regs);
__visible void smp_call_function_single_interrupt(struct pt_regs *r);
#define cpu_physical_id(cpu) per_cpu(x86_cpu_to_apicid, cpu)
-#define cpu_acpi_id(cpu) per_cpu(x86_cpu_to_acpiid, cpu)
/*
* This function is needed by all SMP systems. It must _always_ be valid
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index a3f2fb1fea1b..ceba24f65ae3 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -1848,3 +1848,23 @@ void __iomem * (*acpi_os_ioremap)(acpi_physical_address phys, acpi_size size) =
x86_acpi_os_ioremap;
EXPORT_SYMBOL_GPL(acpi_os_ioremap);
#endif
+
+int acpi_get_cpu_uid(unsigned int cpu, u32 *uid)
+{
+ u32 acpi_id;
+
+ if (cpu >= nr_cpu_ids)
+ return -EINVAL;
+
+#ifdef CONFIG_SMP
+ acpi_id = per_cpu(x86_cpu_to_acpiid, cpu);
+ if (acpi_id == CPU_ACPIID_INVALID)
+ return -ENODEV;
+#else
+ acpi_id = 0;
+#endif
+
+ *uid = acpi_id;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(acpi_get_cpu_uid);
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index fe57ff85d004..2f9fa27e5a3c 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -151,6 +151,7 @@ static void xen_hvm_crash_shutdown(struct pt_regs *regs)
static int xen_cpu_up_prepare_hvm(unsigned int cpu)
{
+ u32 cpu_uid;
int rc = 0;
/*
@@ -161,8 +162,8 @@ static int xen_cpu_up_prepare_hvm(unsigned int cpu)
*/
xen_uninit_lock_cpu(cpu);
- if (cpu_acpi_id(cpu) != CPU_ACPIID_INVALID)
- per_cpu(xen_vcpu_id, cpu) = cpu_acpi_id(cpu);
+ if (acpi_get_cpu_uid(cpu, &cpu_uid) == 0)
+ per_cpu(xen_vcpu_id, cpu) = cpu_uid;
else
per_cpu(xen_vcpu_id, cpu) = cpu;
xen_vcpu_setup(cpu);
--
2.17.1
^ permalink raw reply related
* [PATCH RESEND v10 2/8] LoongArch: Add acpi_get_cpu_uid() for unified ACPI CPU UID retrieval
From: Chengwen Feng @ 2026-04-01 8:16 UTC (permalink / raw)
To: Bjorn Helgaas, Catalin Marinas, Will Deacon, Rafael J . Wysocki
Cc: Jonathan Corbet, WANG Xuerui, Thomas Gleixner, Dave Hansen,
H . Peter Anvin, Juergen Gross, Boris Ostrovsky, Len Brown,
Sunil V L, Mark Rutland, Jonathan Cameron, Kees Cook, Yanteng Si,
Sean Christopherson, Kai Huang, Tom Lendacky, Thomas Huth,
Thorsten Blum, Kevin Loughlin, Zheyun Shen, Peter Zijlstra,
Pawan Gupta, Xin Li, Ahmed S . Darwish, Sohil Mehta,
Ilkka Koskinen, Robin Murphy, James Clark, Besar Wicaksono, Ma Ke,
Wei Huang, Andy Gospodarek, Somnath Kotur, punit.agrawal,
guohanjun, suzuki.poulose, ryan.roberts, chenl311, masahiroy,
wangyuquan1236, anshuman.khandual, heinrich.schuchardt,
Eric.VanTassell, wangzhou1, wanghuiqiang, liuyonglong,
fengchengwen, linux-pci, linux-doc, linux-kernel,
linux-arm-kernel, loongarch, linux-riscv, xen-devel, linux-acpi,
linux-perf-users, stable, x86
In-Reply-To: <20260401081640.26875-1-fengchengwen@huawei.com>
As a step towards unifying the interface for retrieving ACPI CPU UID
across architectures, introduce a new function acpi_get_cpu_uid() for
loongarch. While at it, add input validation to make the code more
robust.
Cc: stable@vger.kernel.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
---
arch/loongarch/include/asm/acpi.h | 1 +
arch/loongarch/kernel/acpi.c | 9 +++++++++
2 files changed, 10 insertions(+)
diff --git a/arch/loongarch/include/asm/acpi.h b/arch/loongarch/include/asm/acpi.h
index 7376840fa9f7..8bb101b4557e 100644
--- a/arch/loongarch/include/asm/acpi.h
+++ b/arch/loongarch/include/asm/acpi.h
@@ -44,6 +44,7 @@ static inline u32 get_acpi_id_for_cpu(unsigned int cpu)
{
return acpi_core_pic[cpu_logical_map(cpu)].processor_id;
}
+int acpi_get_cpu_uid(unsigned int cpu, u32 *uid);
#endif /* !CONFIG_ACPI */
diff --git a/arch/loongarch/kernel/acpi.c b/arch/loongarch/kernel/acpi.c
index 1367ca759468..058f0dbe8e8f 100644
--- a/arch/loongarch/kernel/acpi.c
+++ b/arch/loongarch/kernel/acpi.c
@@ -385,3 +385,12 @@ int acpi_unmap_cpu(int cpu)
EXPORT_SYMBOL(acpi_unmap_cpu);
#endif /* CONFIG_ACPI_HOTPLUG_CPU */
+
+int acpi_get_cpu_uid(unsigned int cpu, u32 *uid)
+{
+ if (cpu >= nr_cpu_ids)
+ return -EINVAL;
+ *uid = acpi_core_pic[cpu_logical_map(cpu)].processor_id;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(acpi_get_cpu_uid);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v8 04/10] x86/vmscape: Rename x86_ibpb_exit_to_user to x86_predictor_flush_exit_to_user
From: Pawan Gupta @ 2026-04-01 8:13 UTC (permalink / raw)
To: Sean Christopherson
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Borislav Petkov, Dave Hansen, Peter Zijlstra,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, KP Singh,
Jiri Olsa, David S. Miller, David Laight, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, David Ahern, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Paolo Bonzini, Jonathan Corbet,
linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <acwJVUeW9KoLft4d@google.com>
On Tue, Mar 31, 2026 at 10:50:13AM -0700, Sean Christopherson wrote:
> On Tue, Mar 24, 2026, Pawan Gupta wrote:
> > With the upcoming changes x86_ibpb_exit_to_user will also be used when BHB
> > clearing sequence is used. Rename it cover both the cases.
> >
> > No functional change.
> >
> > Suggested-by: Sean Christopherson <seanjc@google.com>
> > Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> > ---
>
> Acked-by: Sean Christopherson <seanjc@google.com>
Thanks.
^ permalink raw reply
* Re: [PATCH v8 02/10] x86/bhi: Make clear_bhb_loop() effective on newer CPUs
From: Pawan Gupta @ 2026-04-01 8:12 UTC (permalink / raw)
To: David Laight
Cc: Borislav Petkov, x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin,
Josh Poimboeuf, David Kaplan, Sean Christopherson, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
Andy Lutomirski, Thomas Gleixner, Ingo Molnar, David Ahern,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, Stanislav Fomichev, Hao Luo, Paolo Bonzini,
Jonathan Corbet, linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf,
netdev, linux-doc
In-Reply-To: <20260328100837.7e6dc7fe@pumpkin>
On Sat, Mar 28, 2026 at 10:08:37AM +0000, David Laight wrote:
> On Fri, 27 Mar 2026 17:42:56 -0700
> Pawan Gupta <pawan.kumar.gupta@linux.intel.com> wrote:
>
> > On Thu, Mar 26, 2026 at 01:29:31PM -0700, Pawan Gupta wrote:
> > > On Thu, Mar 26, 2026 at 10:45:57AM +0000, David Laight wrote:
> > > > On Thu, 26 Mar 2026 11:01:20 +0100
> > > > Borislav Petkov <bp@alien8.de> wrote:
> > > >
> > > > > On Thu, Mar 26, 2026 at 01:39:34AM -0700, Pawan Gupta wrote:
> > > > > > I believe the equivalent for cpu_feature_enabled() in asm is the
> > > > > > ALTERNATIVE. Please let me know if I am missing something.
> > > > >
> > > > > Yes, you are.
> > > > >
> > > > > The point is that you don't want to stick those alternative calls inside some
> > > > > magic bhb_loop function but hand them in from the outside, as function
> > > > > arguments.
> > > > >
> > > > > Basically what I did.
> > > > >
> > > > > Then you were worried about this being C code and it had to be noinstr... So
> > > > > that outer function can be rewritten in asm, I think, and still keep it well
> > > > > separate.
> > > > >
> > > > > I'll try to rewrite it once I get a free minute, and see how it looks.
> > > > >
> > > >
> > > > I think someone tried getting C code to write the values to global data
> > > > and getting the asm to read them.
> > > > That got discounted because it spilt things between two largely unrelated files.
> > >
> > >
> > > The implementation with global variables wasn't that bad, let me revive it.
> > >
> > > This part which ties sequence to BHI mitigation, which is not ideal,
> > > (because VMSCAPE also uses it) it does seems a cleaner option.
> > >
> > > --- a/arch/x86/kernel/cpu/bugs.c
> > > +++ b/arch/x86/kernel/cpu/bugs.c
> > > @@ -2095,6 +2095,11 @@ static void __init bhi_select_mitigation(void)
> > >
> > > static void __init bhi_update_mitigation(void)
> > > {
> > > + if (!cpu_feature_enabled(X86_FEATURE_BHI_CTRL)) {
> > > + bhi_seq_outer_loop = 5;
> > > + bhi_seq_inner_loop = 5;
> > > + }
> > > +
> > >
> > > I believe this can be moved to somewhere common to all mitigations.
> > >
> > > > I think the BPF code would need significant refactoring to call a C function.
> > >
> > > Ya, true. Will use globals and keep clear_bhb_loop() in asm.
> >
> > While testing this approach, I noticed that syscalls were suffering an 8%
> > regression on ICX for Native BHI mitigation:
> >
> > $ perf bench syscall basic -l 100000000
> >
> > Bisection pointed to the change for using 8-bit registers (al/ah replacing
> > eax/ecx) as the main contributor to the regression. (Global variables added
> > a bit, but within noise).
> >
> > Further digging revealed a strange behavior, using %ah for the inner loop
> > was causing the regression, interchanging %al and %ah in the loops
> > (for movb and sub) eliminated the regression.
> >
> > <clear_bhb_loop_nofence>:
> >
> > movb bhb_seq_outer_loop(%rip), %al
> >
> > call 1f
> > jmp 5f
> > 1: call 2f
> > .Lret1: RET
> > 2: movb bhb_seq_inner_loop(%rip), %ah
> > 3: jmp 4f
> > nop
> > 4: sub $1, %ah <---- No regression with %al here
> > jnz 3b
> > sub $1, %al
> > jnz 1b
> >
> > My guess is, "sub $1, %al" is faster than "sub $1, %ah". Using %al in the
> > inner loop, which is executed more number of times is likely making the
> > difference. A perf profile is needed to confirm this.
>
> I bet it is also CPU dependant - it is quite likely that there isn't
> any special hardware to support partial writes of %ah so it ends up taking
> a slow path (possibly even a microcoded one to get an 8% regression).
Strangely, %ah in the inner loop incurs less uops and has fewer branch
misses, yet takes more cycles. Below is the perf data for the sequence on a
Rocket Lake (similar observation on ICX and EMR):
Event %al inner %ah inner Delta
---------------------- ------------- ------------- ----------
cycles 776,775,020 972,322,384 +25.2%
instructions/cycle 1.23 0.98 -20.3%
branch-misses 4,792,502 560,449 -88.3%
uops_issued.any 768,019,010 696,888,357 -9.3%
time elapsed 0.1627s 0.2048s +25.9%
Time elapsed directly correlates with the increase in cycles.
> As well as swapping %al <-> %ah try changing the outer loop decrement to
> sub $0x100, %ax
> since %al is zero that will set the z flag the same.
Unfortunately, using "sub $0x100, %ax"(with %al as inner loop) isn't better
than just using "sub $1, %ah" in the outer loop:
Event %al inner + sub %ax Delta
---------------------- ------------- ------------- ----------
cycles 776,775,020 813,372,036 +4.7%
instructions/cycle 1.23 1.17 -4.5%
branch-misses 4,792,502 7,610,323 +58.8%
uops_issued.any 768,019,010 827,465,137 +7.7%
time elapsed 0.1627s 0.1707s +4.9%
> I've just hacked a test into some test code I've got.
> I'm not seeing an unexpected costs on either zen-5 or haswell.
> So it may be more subtle.
This is puzzling, but atleast it is evident that using %al for the inner
loop seems to be the best option. In summary:
Variant Cycles Uops Issued Branch Misses
------- ---------- ----------- -------------
%al 776M 768M 4.8M (fastest)
%ah 972M (+25%) 697M (-9%) 560K (-88%) (fewer uops + misses, yet slowest)
sub %ax 813M (+5%) 827M (+8%) 7.6M (+59%) (most uops + misses)
^ permalink raw reply
* Re: [PATCH v2 1/2] drm: Rename drm_atomic_state
From: Thomas Zimmermann @ 2026-04-01 8:12 UTC (permalink / raw)
To: Maxime Ripard
Cc: David Airlie, Simona Vetter, Maarten Lankhorst, Jonathan Corbet,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Alex Deucher, Christian König, Rob Clark, Dmitry Baryshkov,
Andrzej Hajda, Neil Armstrong, Robert Foss, Dave Stevenson,
Laurent Pinchart, dri-devel, linux-doc, Simona Vetter
In-Reply-To: <20260401-imperial-tan-emu-0a1ab4@houat>
Hi
Am 01.04.26 um 10:06 schrieb Maxime Ripard:
> Hi Thomas,
>
> On Wed, Apr 01, 2026 at 08:05:12AM +0200, Thomas Zimmermann wrote:
>> Am 31.03.26 um 16:41 schrieb Maxime Ripard:
>>> The KMS framework uses two slightly different definitions for the state
>>> concept. For a given object (plane, CRTC, encoder, etc., so
>>> drm_$OBJECT_state), the state is the entire state of that object.
>>> However, at the device level, drm_atomic_state refers to a state update
>>> for a limited number of objects.
>>>
>>> Thus, drm_atomic_state isn't the entire device state, but only the full
>>> state of some objects in that device. This has been an endless source of
>>> confusion and thus bugs.
>>>
>>> We can rename drm_atomic_state to drm_atomic_commit to make it less
>>> confusing.
>> Nit: The subject should already spell out the new name.
>>
>>> This patch was created using:
>>>
>>> rg -l drm_atomic_state | \
>>> xargs sed -i 's/drm_atomic_state/drm_atomic_commit/g; s/drm_atomic_commit_helper/drm_atomic_state_helper/g'
>>> mv drivers/gpu/drm/tests/drm_atomic_state_test.c drivers/gpu/drm/tests/drm_atomic_commit_test.c
>> We now have many places that read like "struct drm_atomic_commit *state',
>> which mixes up terminology. Is there a way of transforming this
>> automatically to use 'commit' for the variable's name?
> I know what you're saying, but it would be much more intrusive and I'm
> not sure I feel comfortable doing it in one go. I had a try this morning
> to come up with a coccinelle script and it looks like it chokes up a bit
> on it too.
>
> I'm sure we could blame my coccinelle skills, but how about we do this
> driver by driver later on? I can do it if you want me to, and we don't
> really need to have that one big commit, it can be split into smaller
> units that would be easier to test and merge.
No problem, there's no hurry. It was just a question.
Best regards
Thomas
>
> Maxime
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v2 1/2] drm: Rename drm_atomic_state
From: Maxime Ripard @ 2026-04-01 8:06 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: David Airlie, Simona Vetter, Maarten Lankhorst, Jonathan Corbet,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Alex Deucher, Christian König, Rob Clark, Dmitry Baryshkov,
Andrzej Hajda, Neil Armstrong, Robert Foss, Dave Stevenson,
Laurent Pinchart, dri-devel, linux-doc, Simona Vetter
In-Reply-To: <316d8ab8-78d0-4169-9264-e4da5424b5d6@suse.de>
[-- Attachment #1: Type: text/plain, Size: 1818 bytes --]
Hi Thomas,
On Wed, Apr 01, 2026 at 08:05:12AM +0200, Thomas Zimmermann wrote:
> Am 31.03.26 um 16:41 schrieb Maxime Ripard:
> > The KMS framework uses two slightly different definitions for the state
> > concept. For a given object (plane, CRTC, encoder, etc., so
> > drm_$OBJECT_state), the state is the entire state of that object.
> > However, at the device level, drm_atomic_state refers to a state update
> > for a limited number of objects.
> >
> > Thus, drm_atomic_state isn't the entire device state, but only the full
> > state of some objects in that device. This has been an endless source of
> > confusion and thus bugs.
> >
> > We can rename drm_atomic_state to drm_atomic_commit to make it less
> > confusing.
>
> Nit: The subject should already spell out the new name.
>
> >
> > This patch was created using:
> >
> > rg -l drm_atomic_state | \
> > xargs sed -i 's/drm_atomic_state/drm_atomic_commit/g; s/drm_atomic_commit_helper/drm_atomic_state_helper/g'
> > mv drivers/gpu/drm/tests/drm_atomic_state_test.c drivers/gpu/drm/tests/drm_atomic_commit_test.c
>
> We now have many places that read like "struct drm_atomic_commit *state',
> which mixes up terminology. Is there a way of transforming this
> automatically to use 'commit' for the variable's name?
I know what you're saying, but it would be much more intrusive and I'm
not sure I feel comfortable doing it in one go. I had a try this morning
to come up with a coccinelle script and it looks like it chokes up a bit
on it too.
I'm sure we could blame my coccinelle skills, but how about we do this
driver by driver later on? I can do it if you want me to, and we don't
really need to have that one big commit, it can be split into smaller
units that would be easier to test and merge.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v03 4/6] hinic3: Add ethtool rss ops
From: Mohsin Bashir @ 2026-04-01 7:53 UTC (permalink / raw)
To: Fan Gong, Zhu Yikai, netdev, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Andrew Lunn,
Ioana Ciornei
Cc: linux-kernel, linux-doc, luosifu, Xin Guo, Zhou Shuai, Wu Like,
Shi Jing, Zheng Jiezhen, Maxime Chevallier
In-Reply-To: <a8347921a7ac11ca7e0db52381be70689b830005.1774940117.git.zhuyikai1@h-partners.com>
> /* hilink mac group command */
> diff --git a/drivers/net/ethernet/huawei/hinic3/hinic3_rss.c b/drivers/net/ethernet/huawei/hinic3/hinic3_rss.c
> index 25db74d8c7dd..1c8aea9d8887 100644
> --- a/drivers/net/ethernet/huawei/hinic3/hinic3_rss.c
> +++ b/drivers/net/ethernet/huawei/hinic3/hinic3_rss.c
> @@ -155,7 +155,7 @@ static int hinic3_set_rss_type(struct hinic3_hwdev *hwdev,
> L2NIC_CMD_SET_RSS_CTX_TBL, &msg_params);
>
> if (ctx_tbl.msg_head.status == MGMT_STATUS_CMD_UNSUPPORTED) {
> - return MGMT_STATUS_CMD_UNSUPPORTED;
> + return -EOPNOTSUPP;
Looks like an unrelated change?
> } else if (err || ctx_tbl.msg_head.status) {
> dev_err(hwdev->dev, "mgmt Failed to set rss context offload, err: %d, status: 0x%x\n",
> err, ctx_tbl.msg_head.status);
> @@ -165,6 +165,39 @@ static int hinic3_set_rss_type(struct hinic3_hwdev *hwdev,
> return 0;
> }
>
> +static int hinic3_set_rss_hash_opts(struct net_device *netdev,
> + struct ethtool_rxnfc *cmd)
> +{
> + struct hinic3_nic_dev *nic_dev = netdev_priv(netdev);
> + struct hinic3_rss_type *rss_type;
> + int err;
> +
> + rss_type = &nic_dev->rss_type;
> +
> + if (!test_bit(HINIC3_RSS_ENABLE, &nic_dev->flags)) {
> + cmd->data = 0;
> + netdev_err(netdev, "RSS is disable, not support to set flow-hash\n");
> + return -EOPNOTSUPP;
> + }
> +
> + /* RSS only supports hashing of IP addresses and L4 ports */
> + if (cmd->data & ~(RXH_IP_SRC | RXH_IP_DST |
> + RXH_L4_B_0_1 | RXH_L4_B_2_3))
> + return -EINVAL;
> +
> + /* Both IP addresses must be part of the hash tuple */
> + if (!(cmd->data & RXH_IP_SRC) || !(cmd->data & RXH_IP_DST))
> + return -EINVAL;
> +
> + err = hinic3_get_rss_type(nic_dev->hwdev, rss_type);
> + if (err) {
> + netdev_err(netdev, "Failed to get rss type\n");
> + return err;
> + }
> +
> + err = hinic3_update_rss_hash_opts(netdev, cmd, rss_type);
> + if (err)
> + return err;
> +
> + err = hinic3_set_rss_type(nic_dev->hwdev, *rss_type);
So if we fail here, we have already modified the rss_type in-place. From
this on-wards, the HW state would diverge from in-memory state. How
about use a local copy and only update if no error?
> + if (err) {
> + netdev_err(netdev, "Failed to set rss type\n");
> + return err;
> + }
> +
> + return 0;
> +}
> +
^ permalink raw reply
* Re: [PATCH net-next v03 3/6] hinic3: Add ethtool coalesce ops
From: Mohsin Bashir @ 2026-04-01 7:53 UTC (permalink / raw)
To: Fan Gong, Zhu Yikai, netdev, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Andrew Lunn,
Ioana Ciornei
Cc: linux-kernel, linux-doc, luosifu, Xin Guo, Zhou Shuai, Wu Like,
Shi Jing, Zheng Jiezhen, Maxime Chevallier
In-Reply-To: <ffc357656b2412abf6e8de4200d289e761f3e6ea.1774940117.git.zhuyikai1@h-partners.com>
> +static int is_coalesce_exceed_limit(struct net_device *netdev,
> + const struct ethtool_coalesce *coal)
> +{
> + const struct {
> + const char *name;
> + u32 value;
> + u32 limit;
> + } coalesce_limits[] = {
> + {"rx_coalesce_usecs",
> + coal->rx_coalesce_usecs,
> + COALESCE_MAX_TIMER_CFG},
> + {"rx_max_coalesced_frames",
> + coal->rx_max_coalesced_frames,
> + COALESCE_MAX_PENDING_LIMIT},
> + {"rx_max_coalesced_frames_low",
> + coal->rx_max_coalesced_frames_low,
> + COALESCE_MAX_PENDING_LIMIT},
> + {"rx_max_coalesced_frames_high",
> + coal->rx_max_coalesced_frames_high,
> + COALESCE_MAX_PENDING_LIMIT},
> + };
> +
> + for (int i = 0; i < ARRAY_SIZE(coalesce_limits); i++) {
> + if (coalesce_limits[i].value > coalesce_limits[i].limit) {
> + netdev_err(netdev, "%s out of range %d-%d\n",
> + coalesce_limits[i].name, 0,
> + coalesce_limits[i].limit);
> + return -EOPNOTSUPP;
Since we are failing a range check, maybe -ERANGE or -EINVAL would be
more appropriate here.
> + }
> + }
> + return 0;
> +}
> +
> +static int is_coalesce_legal(struct net_device *netdev,
> + const struct ethtool_coalesce *coal)
> +{
> + int err;
> +
> + err = is_coalesce_exceed_limit(netdev, coal);
> + if (err)
> + return err;
> +
> + if (coal->rx_max_coalesced_frames_low >=
> + coal->rx_max_coalesced_frames_high &&
> + coal->rx_max_coalesced_frames_high > 0) {
So this would allow non-zero low and zero high. For example, low = 10,
high = 0. Is this expected?
> + netdev_err(netdev, "invalid coalesce frame high %u, low %u, unit %d\n",
> + coal->rx_max_coalesced_frames_high,
> + coal->rx_max_coalesced_frames_low,
> + COALESCE_PENDING_LIMIT_UNIT);
> + return -EOPNOTSUPP;
> + }
> +
> + return 0;
> +}
> +
> +static void check_coalesce_align(struct net_device *netdev,
> + u32 item, u32 unit, const char *str)
> +{
> + if (item % unit)
> + netdev_warn(netdev, "%s in %d units, change to %u\n",
> + str, unit, item - item % unit);
> +}
> +
> +#define CHECK_COALESCE_ALIGN(member, unit) \
> + check_coalesce_align(netdev, member, unit, #member)
> +
> +static void check_coalesce_changed(struct net_device *netdev,
> + u32 item, u32 unit, u32 ori_val,
> + const char *obj_str, const char *str)
> +{
> + if ((item / unit) != ori_val)
> + netdev_dbg(netdev, "Change %s from %d to %u %s\n",
> + str, ori_val * unit, item - item % unit, obj_str);
> +}
> +
> +#define CHECK_COALESCE_CHANGED(member, unit, ori_val, obj_str) \
> + check_coalesce_changed(netdev, member, unit, ori_val, obj_str, #member)
> +
> +static int hinic3_set_hw_coal_param(struct net_device *netdev,
> + struct hinic3_intr_coal_info *intr_coal)
> +{
> + struct hinic3_nic_dev *nic_dev = netdev_priv(netdev);
> + int err;
> + u16 i;
> +
> + for (i = 0; i < nic_dev->max_qps; i++) {
> + err = hinic3_set_queue_coalesce(netdev, i, intr_coal);
> + if (err)
> + return err;
> + }
> +
> + return 0;
> +}
> +
> +static int hinic3_get_coalesce(struct net_device *netdev,
> + struct ethtool_coalesce *coal,
> + struct kernel_ethtool_coalesce *kernel_coal,
> + struct netlink_ext_ack *extack)
> +{
> + struct hinic3_nic_dev *nic_dev = netdev_priv(netdev);
> + struct hinic3_intr_coal_info *interrupt_info;
> +
> + interrupt_info = &nic_dev->intr_coalesce[0];
> +
> + /* TX/RX uses the same interrupt.
> + * So we only declare RX ethtool_coalesce parameters.
> + */
> + coal->rx_coalesce_usecs = interrupt_info->coalesce_timer_cfg *
> + COALESCE_TIMER_CFG_UNIT;
> + coal->rx_max_coalesced_frames = interrupt_info->pending_limit *
> + COALESCE_PENDING_LIMIT_UNIT;
> +
> + coal->use_adaptive_rx_coalesce = nic_dev->adaptive_rx_coal;
> +
> + coal->rx_max_coalesced_frames_high =
> + interrupt_info->rx_pending_limit_high *
> + COALESCE_PENDING_LIMIT_UNIT;
> +
> + coal->rx_max_coalesced_frames_low =
> + interrupt_info->rx_pending_limit_low *
> + COALESCE_PENDING_LIMIT_UNIT;
> +
> + return 0;
> +}
> +
> +static int hinic3_set_coalesce(struct net_device *netdev,
> + struct ethtool_coalesce *coal,
> + struct kernel_ethtool_coalesce *kernel_coal,
> + struct netlink_ext_ack *extack)
> +{
> + struct hinic3_nic_dev *nic_dev = netdev_priv(netdev);
> + struct hinic3_intr_coal_info *ori_intr_coal;
> + struct hinic3_intr_coal_info intr_coal = {};
> + char obj_str[32];
> + int err;
> +
> + err = is_coalesce_legal(netdev, coal);
> + if (err)
> + return err;
> +
> + CHECK_COALESCE_ALIGN(coal->rx_coalesce_usecs, COALESCE_TIMER_CFG_UNIT);
> + CHECK_COALESCE_ALIGN(coal->rx_max_coalesced_frames,
> + COALESCE_PENDING_LIMIT_UNIT);
> + CHECK_COALESCE_ALIGN(coal->rx_max_coalesced_frames_high,
> + COALESCE_PENDING_LIMIT_UNIT);
> + CHECK_COALESCE_ALIGN(coal->rx_max_coalesced_frames_low,
> + COALESCE_PENDING_LIMIT_UNIT);
> +
> + ori_intr_coal = &nic_dev->intr_coalesce[0];
> + snprintf(obj_str, sizeof(obj_str), "for netdev");
> +
> + CHECK_COALESCE_CHANGED(coal->rx_coalesce_usecs, COALESCE_TIMER_CFG_UNIT,
> + ori_intr_coal->coalesce_timer_cfg, obj_str);
> + CHECK_COALESCE_CHANGED(coal->rx_max_coalesced_frames,
> + COALESCE_PENDING_LIMIT_UNIT,
> + ori_intr_coal->pending_limit, obj_str);
> + CHECK_COALESCE_CHANGED(coal->rx_max_coalesced_frames_high,
> + COALESCE_PENDING_LIMIT_UNIT,
> + ori_intr_coal->rx_pending_limit_high, obj_str);
> + CHECK_COALESCE_CHANGED(coal->rx_max_coalesced_frames_low,
> + COALESCE_PENDING_LIMIT_UNIT,
> + ori_intr_coal->rx_pending_limit_low, obj_str);
> +
> + intr_coal.coalesce_timer_cfg =
> + (u8)(coal->rx_coalesce_usecs / COALESCE_TIMER_CFG_UNIT);
> + intr_coal.pending_limit = (u8)(coal->rx_max_coalesced_frames /
> + COALESCE_PENDING_LIMIT_UNIT);
> +
> + nic_dev->adaptive_rx_coal = coal->use_adaptive_rx_coalesce;
> +
> + intr_coal.rx_pending_limit_high =
> + (u8)(coal->rx_max_coalesced_frames_high /
> + COALESCE_PENDING_LIMIT_UNIT);
> +
> + intr_coal.rx_pending_limit_low =
> + (u8)(coal->rx_max_coalesced_frames_low /
> + COALESCE_PENDING_LIMIT_UNIT);
> +
> + /* coalesce timer or pending set to zero will disable coalesce */
> + if (!nic_dev->adaptive_rx_coal &&
> + (!intr_coal.coalesce_timer_cfg || !intr_coal.pending_limit))
> + netdev_warn(netdev, "Coalesce will be disabled\n");
> +
> + return hinic3_set_hw_coal_param(netdev, &intr_coal);
> +}
> +
> static const struct ethtool_ops hinic3_ethtool_ops = {
> - .supported_coalesce_params = ETHTOOL_COALESCE_USECS |
> - ETHTOOL_COALESCE_PKT_RATE_RX_USECS,
> + .supported_coalesce_params = ETHTOOL_COALESCE_RX_USECS |
> + ETHTOOL_COALESCE_RX_MAX_FRAMES |
> + ETHTOOL_COALESCE_USE_ADAPTIVE_RX |
> + ETHTOOL_COALESCE_RX_MAX_FRAMES_LOW |
> + ETHTOOL_COALESCE_RX_MAX_FRAMES_HIGH,
Looks like ETHTOOL_COALESCE_TX_USECS support got dropped. is it intentional?
> .get_link_ksettings = hinic3_get_link_ksettings,
> .get_drvinfo = hinic3_get_drvinfo,
> .get_msglevel = hinic3_get_msglevel,
> @@ -1004,6 +1231,8 @@ static const struct ethtool_ops hinic3_ethtool_ops = {
> .get_eth_ctrl_stats = hinic3_get_eth_ctrl_stats,
> .get_rmon_stats = hinic3_get_rmon_stats,
> .get_pause_stats = hinic3_get_pause_stats,
> + .get_coalesce = hinic3_get_coalesce,
> + .set_coalesce = hinic3_set_coalesce,
> };
>
> void hinic3_set_ethtool_ops(struct net_device *netdev)
^ permalink raw reply
* Re: [PATCH net-next v03 2/6] hinic3: Add ethtool statistic ops
From: Mohsin Bashir @ 2026-04-01 7:52 UTC (permalink / raw)
To: Fan Gong, Zhu Yikai, netdev, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Andrew Lunn,
Ioana Ciornei
Cc: linux-kernel, linux-doc, luosifu, Xin Guo, Zhou Shuai, Wu Like,
Shi Jing, Zheng Jiezhen, Maxime Chevallier
In-Reply-To: <d3256c3049445bfa9c6b98832d25eaa712422ae6.1774940117.git.zhuyikai1@h-partners.com>
> +
> +static void hinic3_get_qp_stats_strings(const struct net_device *netdev,
Any strong reason to add const here? netdev_priv() would just strip it
anyway. No?
> + char *p)
> +{
> + struct hinic3_nic_dev *nic_dev = netdev_priv(netdev);
> + u8 *data = p;
> + u16 i, j;
> +
> + for (i = 0; i < nic_dev->q_params.num_qps; i++) {
> + for (j = 0; j < ARRAY_SIZE(hinic3_tx_queue_stats); j++)
> + ethtool_sprintf(&data,
> + hinic3_tx_queue_stats[j].name, i);
> + }
> +
> + for (i = 0; i < nic_dev->q_params.num_qps; i++) {
> + for (j = 0; j < ARRAY_SIZE(hinic3_rx_queue_stats); j++)
> + ethtool_sprintf(&data,
> + hinic3_rx_queue_stats[j].name, i);
> + }
> +}
> +
^ 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