This patchset converts all remaining cpufreq users to rely on the
__free(put_cpufreq_policy) annotation for policy references, instead of
calling cpufreq_cpu_put() manually.

Motivation:
- Reduce the chance of reference counting mistakes
- Make the code more consistent with the latest kernel style
- behavior remains the same, but reference counting is now safer 
  and easier to maintain.

The changes are split into 6 patches as they touch different subsystems
and are maintained by different people. There is no functional change.

V5:
 - drop 4 patches
 - change return value int topology.c suggested by Jonathan Cameron
 - fix code in processor_thermal.c suggested by Rafael and Jonathan Cameron
 - fix code in intel_pstate.c suggested by Rafael
 - fix code in governor_passive.c suggested Jonathan Cameron
 - fix code in energy_model.c suggested by Rafael and Krzysztof Kozlowski

V4:
 - Fix compile error in topology.c
 - drop 2 patches
 - Move code into a function in processor_thermal.c
 - Move code into a function in intel_pstate.c
 - Move policy declare in dtpm_cpu.c
 - Fix compile error in imx_thermal.c
 - Fix compile error in ti-thermal-common.c
 - Fix compile error in energy_model.c

V3:
 - drop patch 'KVM: x86: Use __free(put_cpufreq_policy) for policy reference'
 - removed 5 patches which has been applied
 - Consolidate CPUFreq policy assignments and allocations into one line,
   suggested by Ben Horgan
 - Change cpu_has_cpufreq() return type to bool, following Rafael's suggestion
 - Change the title to 'Use scope-based cleanup helper'

V2:
 - Fix compile error in powernv-cpufreq.c
 - Split patch to separate logical changes

Zihuan Zhang (6):
  arm64: topology: Use scope-based cleanup helper
  ACPI: processor: thermal: Use scope-based cleanup helper
  cpufreq: intel_pstate: Use scope-based cleanup helper
  PM / devfreq: Use scope-based cleanup helper
  drm/i915: Use scope-based cleanup helper
  PM: EM: Use scope-based cleanup helper

 arch/arm64/kernel/topology.c        | 11 ++----
 drivers/acpi/processor_thermal.c    | 52 +++++++++++++------------
 drivers/cpufreq/intel_pstate.c      | 59 +++++++++++++++-------------
 drivers/devfreq/governor_passive.c  | 60 +++++++++++------------------
 drivers/gpu/drm/i915/gt/intel_llc.c |  4 +-
 kernel/power/energy_model.c         |  9 +----
 6 files changed, 89 insertions(+), 106 deletions(-)

-- 
2.25.1

On Fri, Sep 05, 2025 at 09:24:07PM +0800, Zihuan Zhang wrote:
> This patchset converts all remaining cpufreq users to rely on the
> __free(put_cpufreq_policy) annotation for policy references, instead of
> calling cpufreq_cpu_put() manually.

Sep 01 Zihuan Zhang ( :8.6K|) [PATCH v3 00/12] cpufreq: use __free() for all cpufreq_cpu_get() references
Sep 03 Zihuan Zhang ( :  65|) [PATCH v4 00/10] cpufreq: use __free() for all cpufreq_cpu_get() references
Sep 05 Zihuan Zhang ( :8.3K|) [PATCH v5 0/6] cpufreq: use __free() for all cpufreq_cpu_get() references

Please stop the spamming. While waiting, go read how this kernel process thing
works:

From: Documentation/process/submitting-patches.rst

Don't get discouraged - or impatient
------------------------------------

After you have submitted your change, be patient and wait.  Reviewers are
busy people and may not get to your patch right away.

Once upon a time, patches used to disappear into the void without comment,
but the development process works more smoothly than that now.  You should
receive comments within a week or so; if that does not happen, make sure
that you have sent your patches to the right place.  Wait for a minimum of
one week before resubmitting or pinging reviewers - possibly longer during
busy times like merge windows.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

在 2025/9/6 01:49, Borislav Petkov 写道:
> On Fri, Sep 05, 2025 at 09:24:07PM +0800, Zihuan Zhang wrote:
>> This patchset converts all remaining cpufreq users to rely on the
>> __free(put_cpufreq_policy) annotation for policy references, instead of
>> calling cpufreq_cpu_put() manually.
> Sep 01 Zihuan Zhang ( :8.6K|) [PATCH v3 00/12] cpufreq: use __free() for all cpufreq_cpu_get() references
> Sep 03 Zihuan Zhang ( :  65|) [PATCH v4 00/10] cpufreq: use __free() for all cpufreq_cpu_get() references
> Sep 05 Zihuan Zhang ( :8.3K|) [PATCH v5 0/6] cpufreq: use __free() for all cpufreq_cpu_get() references
>
> Please stop the spamming. While waiting, go read how this kernel process thing
> works:
>
> From: Documentation/process/submitting-patches.rst
>
> Don't get discouraged - or impatient
> ------------------------------------
>
> After you have submitted your change, be patient and wait.  Reviewers are
> busy people and may not get to your patch right away.
>
> Once upon a time, patches used to disappear into the void without comment,
> but the development process works more smoothly than that now.  You should
> receive comments within a week or so; if that does not happen, make sure
> that you have sent your patches to the right place.  Wait for a minimum of
> one week before resubmitting or pinging reviewers - possibly longer during
> busy times like merge windows.
Sorry for the noise. I’ll split the patchset and avoid CC’ing 
unnecessary people in the future.

Thanks for the reminder!

On Mon, Sep 08, 2025 at 05:12:37PM +0800, Zihuan Zhang wrote:
> > From: Documentation/process/submitting-patches.rst
> > 
> > Don't get discouraged - or impatient
> > ------------------------------------
> > 
> > After you have submitted your change, be patient and wait.  Reviewers are
> > busy people and may not get to your patch right away.
> > 
> > Once upon a time, patches used to disappear into the void without comment,
> > but the development process works more smoothly than that now.  You should
> > receive comments within a week or so; if that does not happen, make sure
> > that you have sent your patches to the right place.  Wait for a minimum of
> > one week before resubmitting or pinging reviewers - possibly longer during
> > busy times like merge windows.
> Sorry for the noise. I’ll split the patchset and avoid CC’ing unnecessary
> people in the future.

I don't think you read what I sent you. Lemme spell it out: you're supposed to
*wait* to gather review feedback, at least a week. While waiting,
*incorporate* or *address* all that feedback and *then* send a new set.

If you keep spamming people like that, you'll accomplish the opposite of what
you're trying to do.

And while waiting you can read our documentation on the community process so
that you know what to do in the future.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette