Hi Rafael, Pierre,

This series adds support for handling ACPI CPPC Highest Performance
register changes at runtime, triggered by Notify(0x85) on a processor
device.

When the platform changes the Highest Performance value (e.g. due to
thermal or power budget adjustments), the OSPM must re-evaluate the
cached capability and propagate the change to the cpufreq policy,
the scheduler's CPU capacity model, and the frequency invariance
engine.

The series is split into three patches:
  Patch 1: Core update_limits callback with boost QoS handling.
  Patch 2: Refactor autonomous perf bounds into a reusable helper
           and wire it into update_limits with error logging.
  Patch 3: Topology subsystem runtime capacity updates with
           validation, early-return optimization, and concurrent-safe
           normalization.

v4 -> v5:
  - Move cpu_data and caps pointer assignments after
    guard(cpufreq_policy_write) in cppc_cpufreq_update_limits() to
    avoid potential use-after-free if concurrent CPU offline frees
    driver_data before the lock is acquired (Sashiko)
  - Extract cppc_cpufreq_sync_boost_limits() from update_limits to
    handle boost_supported re-evaluation, cpuinfo.max_freq tracking,
    and boost_freq_req QoS update in a dedicated helper. The helper
    always updates the QoS request (even when boost becomes
    unsupported) to clear stale constraint values, and forcibly
    disables boost_enabled when boost disappears at runtime
  - Add highest_perf validation in topology_update_cpu_capacity():
    reject values below lowest_perf to prevent corrupted register
    reads from propagating into the scheduler capacity model
  - Add early-return in topology_update_cpu_capacity() when
    raw_capacity[cpu] is unchanged, avoiding redundant normalization
    and schedule_work() calls
  - Add zero capacity_scale guard in topology_update_cpu_capacity()
    to prevent division by zero in the normalization loop
  - Move guard(mutex) before the raw_capacity NULL check so that
    the pointer read is protected by the lock
  - Add CONFIG_GENERIC_ARCH_TOPOLOGY guard with no-op stub in
    arch_topology.h for configs where the topology subsystem is
    disabled

Xueqin Luo (3):
  cpufreq: cppc: Add update_limits support for Highest Performance
    changes
  cpufreq: cppc: Refactor autonomous perf bounds into helper
  arch_topology: Add topology_update_cpu_capacity() for runtime updates

 drivers/base/arch_topology.c   |  76 ++++++++++++++++
 drivers/cpufreq/cppc_cpufreq.c | 157 ++++++++++++++++++++++++++++++---
 include/linux/arch_topology.h  |  13 +++
 3 files changed, 233 insertions(+), 13 deletions(-)

-- 
2.43.0

On 8/7/2026 2:08 PM, Xueqin Luo wrote:
> Hi Rafael, Pierre,
> 
> This series adds support for handling ACPI CPPC Highest Performance
> register changes at runtime, triggered by Notify(0x85) on a processor
> device.
> 
> When the platform changes the Highest Performance value (e.g. due to
> thermal or power budget adjustments), the OSPM must re-evaluate the
> cached capability and propagate the change to the cpufreq policy,
> the scheduler's CPU capacity model, and the frequency invariance
> engine.
Any real use case of this on platforms that run cppc_cpufreq drivers?
Some addtional motivation may help.

For example, a processor can age over time and its core frequency degrades.
It's good if platforms can make OSPM and userspace aware of this.
> 
> The series is split into three patches:
>   Patch 1: Core update_limits callback with boost QoS handling.
>   Patch 2: Refactor autonomous perf bounds into a reusable helper
>            and wire it into update_limits with error logging.
>   Patch 3: Topology subsystem runtime capacity updates with
>            validation, early-return optimization, and concurrent-safe
>            normalization.
> 
> v4 -> v5:
>   - Move cpu_data and caps pointer assignments after
>     guard(cpufreq_policy_write) in cppc_cpufreq_update_limits() to
>     avoid potential use-after-free if concurrent CPU offline frees
>     driver_data before the lock is acquired (Sashiko)
>   - Extract cppc_cpufreq_sync_boost_limits() from update_limits to
>     handle boost_supported re-evaluation, cpuinfo.max_freq tracking,
>     and boost_freq_req QoS update in a dedicated helper. The helper
>     always updates the QoS request (even when boost becomes
>     unsupported) to clear stale constraint values, and forcibly
>     disables boost_enabled when boost disappears at runtime
>   - Add highest_perf validation in topology_update_cpu_capacity():
>     reject values below lowest_perf to prevent corrupted register
>     reads from propagating into the scheduler capacity model
>   - Add early-return in topology_update_cpu_capacity() when
>     raw_capacity[cpu] is unchanged, avoiding redundant normalization
>     and schedule_work() calls
>   - Add zero capacity_scale guard in topology_update_cpu_capacity()
>     to prevent division by zero in the normalization loop
>   - Move guard(mutex) before the raw_capacity NULL check so that
>     the pointer read is protected by the lock
>   - Add CONFIG_GENERIC_ARCH_TOPOLOGY guard with no-op stub in
>     arch_topology.h for configs where the topology subsystem is
>     disabled
> 
> Xueqin Luo (3):
>   cpufreq: cppc: Add update_limits support for Highest Performance
>     changes
>   cpufreq: cppc: Refactor autonomous perf bounds into helper
>   arch_topology: Add topology_update_cpu_capacity() for runtime updates
> 
>  drivers/base/arch_topology.c   |  76 ++++++++++++++++
>  drivers/cpufreq/cppc_cpufreq.c | 157 ++++++++++++++++++++++++++++++---
>  include/linux/arch_topology.h  |  13 +++
>  3 files changed, 233 insertions(+), 13 deletions(-)
>

On 9/7/26 09:49, Jie Zhan wrote:
> 
> 
> On 8/7/2026 2:08 PM, Xueqin Luo wrote:
>> Hi Rafael, Pierre,
>>
>> This series adds support for handling ACPI CPPC Highest Performance
>> register changes at runtime, triggered by Notify(0x85) on a processor
>> device.
>>
>> When the platform changes the Highest Performance value (e.g. due to
>> thermal or power budget adjustments), the OSPM must re-evaluate the
>> cached capability and propagate the change to the cpufreq policy,
>> the scheduler's CPU capacity model, and the frequency invariance
>> engine.
> Any real use case of this on platforms that run cppc_cpufreq drivers?
> Some addtional motivation may help.
> 
> For example, a processor can age over time and its core frequency degrades.
> It's good if platforms can make OSPM and userspace aware of this.

+1
If this is still current then I'd love to see a resend with a fix to affect
the entire policy at once, not just policy->cpu and I'd propose for now
also limiting highest_perf at first probe and ignoring any
highest_perf_new > highest_perf, until we have a compelling case / platform
that uses it, because IMO it does make everything more complicated.
(+CC Ionela)

> [snip]

On Mon, Sep 21, 2026 at 9:47 PM Christian Loehle
<christian.loehle@arm.com> wrote:
>
> On 9/7/26 09:49, Jie Zhan wrote:
> >
> >
> > On 8/7/2026 2:08 PM, Xueqin Luo wrote:
> >> Hi Rafael, Pierre,
> >>
> >> This series adds support for handling ACPI CPPC Highest Performance
> >> register changes at runtime, triggered by Notify(0x85) on a processor
> >> device.
> >>
> >> When the platform changes the Highest Performance value (e.g. due to
> >> thermal or power budget adjustments), the OSPM must re-evaluate the
> >> cached capability and propagate the change to the cpufreq policy,
> >> the scheduler's CPU capacity model, and the frequency invariance
> >> engine.
> > Any real use case of this on platforms that run cppc_cpufreq drivers?
> > Some addtional motivation may help.
> >
> > For example, a processor can age over time and its core frequency degrades.
> > It's good if platforms can make OSPM and userspace aware of this.
>
> +1

FWIW, this may be related to platform operating mode changes between
"performance" and "powersave" (longer battery life) if the top-most
OPP is a high-cost one.