Powercap controllers frequently expose a hierarchy of power zones (for
example package, clusters and CPUs). Until now, each driver had to
implement its own hierarchy traversal, parent lookup, error handling and
teardown logic.

This series introduces a generic hierarchy description and helper
functions allowing a controller to instantiate and destroy an entire
powercap hierarchy from a static description. The framework takes care of
duplicating the hierarchy description, rebasing parent pointers,
creating zones in dependency order and performing the appropriate
rollback and cleanup on errors.

The series also adds a kselftest exercising the new API by creating a
synthetic hierarchy, validating the exported sysfs hierarchy and
attributes, and ensuring that all resources are correctly released when
the hierarchy is destroyed.

The patches are organized as follows:

1. powercap: Add generic zone hierarchy creation helpers
2. selftests/powercap: Add powercap hierarchy creation API tests

The API was primarily motivated by the recently posted SPEL series and
also provides a migration path for DTPM to use the same generic
infrastructure instead of maintaining its own hierarchy handling.

Link: SPEL cover letter <https://lore.kernel.org/lkml/20260702-qcom_spel_driver_upstream-v3-0-434d50f0c5b0@oss.qualcomm.com/>

Daniel Lezcano (2):
powercap: Add generic zone hierarchy creation helpers
selftests/powercap: Add powercap hierarchy creation API tests

--
2.50.1

Daniel Lezcano (2):
  powercap: Add generic zone hierarchy creation helpers
  selftests/powercap: Add powercap hierarchy creation API tests

 drivers/powercap/powercap_sys.c               | 148 +++++++++++
 include/linux/powercap.h                      | 178 +++++++++++++
 tools/testing/selftests/Makefile              |   1 +
 tools/testing/selftests/powercap/Kbuild       |   3 +
 tools/testing/selftests/powercap/Makefile     |  17 ++
 .../selftests/powercap/powercap_hierarchy.c   | 247 ++++++++++++++++++
 .../selftests/powercap/powercap_hierarchy.sh  | 118 +++++++++
 7 files changed, 712 insertions(+)
 create mode 100644 tools/testing/selftests/powercap/Kbuild
 create mode 100644 tools/testing/selftests/powercap/Makefile
 create mode 100644 tools/testing/selftests/powercap/powercap_hierarchy.c
 create mode 100755 tools/testing/selftests/powercap/powercap_hierarchy.sh

-- 
2.53.0

Hi Rafael,

On 8/6/26 13:01, Daniel Lezcano wrote:
> Powercap controllers frequently expose a hierarchy of power zones (for
> example package, clusters and CPUs). Until now, each driver had to
> implement its own hierarchy traversal, parent lookup, error handling and
> teardown logic.
> 
> This series introduces a generic hierarchy description and helper
> functions allowing a controller to instantiate and destroy an entire
> powercap hierarchy from a static description. The framework takes care of
> duplicating the hierarchy description, rebasing parent pointers,
> creating zones in dependency order and performing the appropriate
> rollback and cleanup on errors.
> 
> The series also adds a kselftest exercising the new API by creating a
> synthetic hierarchy, validating the exported sysfs hierarchy and
> attributes, and ensuring that all resources are correctly released when
> the hierarchy is destroyed.
> 
> The patches are organized as follows:
> 
> 1. powercap: Add generic zone hierarchy creation helpers
> 2. selftests/powercap: Add powercap hierarchy creation API tests
> 
> The API was primarily motivated by the recently posted SPEL series and
> also provides a migration path for DTPM to use the same generic
> infrastructure instead of maintaining its own hierarchy handling.
> 
> Link: SPEL cover letter <https://lore.kernel.org/lkml/20260702-qcom_spel_driver_upstream-v3-0-434d50f0c5b0@oss.qualcomm.com/>
> 
> Daniel Lezcano (2):
> powercap: Add generic zone hierarchy creation helpers
> selftests/powercap: Add powercap hierarchy creation API tests
> 
> --
It was easy to migrate DTPM to this API and AFAICT Manaf was able to 
migrate also its series to this new API.

Is it possible to consider it for merging ?

Thanks

   -- Daniel

[1] 
https://lore.kernel.org/all/20260819165605.1398880-1-daniel.lezcano@oss.qualcomm.com/

[2] 
https://lore.kernel.org/all/20260702-qcom_spel_driver_upstream-v3-0-434d50f0c5b0@oss.qualcomm.com/

Hi Daniel,

On 9/7/2026 3:33 PM, Daniel Lezcano wrote:
> 
> Hi Rafael,
> 
> On 8/6/26 13:01, Daniel Lezcano wrote:
>> Powercap controllers frequently expose a hierarchy of power zones (for
>> example package, clusters and CPUs). Until now, each driver had to
>> implement its own hierarchy traversal, parent lookup, error handling and
>> teardown logic.
>>
>> This series introduces a generic hierarchy description and helper
>> functions allowing a controller to instantiate and destroy an entire
>> powercap hierarchy from a static description. The framework takes care of
>> duplicating the hierarchy description, rebasing parent pointers,
>> creating zones in dependency order and performing the appropriate
>> rollback and cleanup on errors.
>>
>> The series also adds a kselftest exercising the new API by creating a
>> synthetic hierarchy, validating the exported sysfs hierarchy and
>> attributes, and ensuring that all resources are correctly released when
>> the hierarchy is destroyed.
>>
>> The patches are organized as follows:
>>
>> 1. powercap: Add generic zone hierarchy creation helpers
>> 2. selftests/powercap: Add powercap hierarchy creation API tests
>>
>> The API was primarily motivated by the recently posted SPEL series and
>> also provides a migration path for DTPM to use the same generic
>> infrastructure instead of maintaining its own hierarchy handling.
>>
>> Link: SPEL cover letter <https://lore.kernel.org/lkml/20260702- 
>> qcom_spel_driver_upstream-v3-0-434d50f0c5b0@oss.qualcomm.com/>
>>
>> Daniel Lezcano (2):
>> powercap: Add generic zone hierarchy creation helpers
>> selftests/powercap: Add powercap hierarchy creation API tests
>>
>> -- 
> It was easy to migrate DTPM to this API and AFAICT Manaf was able to 
> migrate also its series to this new API.

Yes, I rebased my Qualcomm SPEL powercap driver series on top of this
patch and migrated the series without any issues.
These APIs significantly simplify the driver code for creating and
managing the powercap hierarchy.

Tested-by: Manaf Meethalavalappu Pallikunhi 
<manaf.pallikunhi@oss.qualcomm.com>

Thanks,
Manaf

> 
> Is it possible to consider it for merging ?
> 
> Thanks
> 
>    -- Daniel
> 
> [1] https://lore.kernel.org/all/20260819165605.1398880-1- 
> daniel.lezcano@oss.qualcomm.com/
> 
> [2] https://lore.kernel.org/all/20260702-qcom_spel_driver_upstream- 
> v3-0-434d50f0c5b0@oss.qualcomm.com/

Le 11/09/2026 à 17:44, Manaf Meethalavalappu Pallikunhi a écrit :
> Hi Daniel,
> 
> On 9/7/2026 3:33 PM, Daniel Lezcano wrote:
>>
>> Hi Rafael,
>>
>> On 8/6/26 13:01, Daniel Lezcano wrote:
>>> Powercap controllers frequently expose a hierarchy of power zones (for
>>> example package, clusters and CPUs). Until now, each driver had to
>>> implement its own hierarchy traversal, parent lookup, error handling and
>>> teardown logic.
>>>
>>> This series introduces a generic hierarchy description and helper
>>> functions allowing a controller to instantiate and destroy an entire
>>> powercap hierarchy from a static description. The framework takes 
>>> care of
>>> duplicating the hierarchy description, rebasing parent pointers,
>>> creating zones in dependency order and performing the appropriate
>>> rollback and cleanup on errors.
>>>
>>> The series also adds a kselftest exercising the new API by creating a
>>> synthetic hierarchy, validating the exported sysfs hierarchy and
>>> attributes, and ensuring that all resources are correctly released when
>>> the hierarchy is destroyed.
>>>
>>> The patches are organized as follows:
>>>
>>> 1. powercap: Add generic zone hierarchy creation helpers
>>> 2. selftests/powercap: Add powercap hierarchy creation API tests
>>>
>>> The API was primarily motivated by the recently posted SPEL series and
>>> also provides a migration path for DTPM to use the same generic
>>> infrastructure instead of maintaining its own hierarchy handling.
>>>
>>> Link: SPEL cover letter <https://lore.kernel.org/lkml/20260702- 
>>> qcom_spel_driver_upstream-v3-0-434d50f0c5b0@oss.qualcomm.com/>
>>>
>>> Daniel Lezcano (2):
>>> powercap: Add generic zone hierarchy creation helpers
>>> selftests/powercap: Add powercap hierarchy creation API tests
>>>
>>> -- 
>> It was easy to migrate DTPM to this API and AFAICT Manaf was able to 
>> migrate also its series to this new API.
> 
> Yes, I rebased my Qualcomm SPEL powercap driver series on top of this
> patch and migrated the series without any issues.
> These APIs significantly simplify the driver code for creating and
> managing the powercap hierarchy.
> 
> Tested-by: Manaf Meethalavalappu Pallikunhi 
> <manaf.pallikunhi@oss.qualcomm.com>

Great! Thanks Manaf

Hi Daniel,

On 9/7/26 11:03, Daniel Lezcano wrote:
> 
> Hi Rafael,
> 
> On 8/6/26 13:01, Daniel Lezcano wrote:
>> Powercap controllers frequently expose a hierarchy of power zones (for
>> example package, clusters and CPUs). Until now, each driver had to
>> implement its own hierarchy traversal, parent lookup, error handling and
>> teardown logic.
>>
>> This series introduces a generic hierarchy description and helper
>> functions allowing a controller to instantiate and destroy an entire
>> powercap hierarchy from a static description. The framework takes care of
>> duplicating the hierarchy description, rebasing parent pointers,
>> creating zones in dependency order and performing the appropriate
>> rollback and cleanup on errors.
>>
>> The series also adds a kselftest exercising the new API by creating a
>> synthetic hierarchy, validating the exported sysfs hierarchy and
>> attributes, and ensuring that all resources are correctly released when
>> the hierarchy is destroyed.
>>
>> The patches are organized as follows:
>>
>> 1. powercap: Add generic zone hierarchy creation helpers
>> 2. selftests/powercap: Add powercap hierarchy creation API tests
>>
>> The API was primarily motivated by the recently posted SPEL series and
>> also provides a migration path for DTPM to use the same generic
>> infrastructure instead of maintaining its own hierarchy handling.
>>
>> Link: SPEL cover letter <https://lore.kernel.org/lkml/20260702- 
>> qcom_spel_driver_upstream-v3-0-434d50f0c5b0@oss.qualcomm.com/>
>>
>> Daniel Lezcano (2):
>> powercap: Add generic zone hierarchy creation helpers
>> selftests/powercap: Add powercap hierarchy creation API tests
>>
>> -- 
> It was easy to migrate DTPM to this API and AFAICT Manaf was able to 
> migrate also its series to this new API.
> 
> Is it possible to consider it for merging ?

I will do a review for this patch set today...

I can see some potential improvements there.

Regards,
Lukasz

Hi,


On 9/7/26 12:46, Lukasz Luba wrote:
> Hi Daniel,
> 
> On 9/7/26 11:03, Daniel Lezcano wrote:
>>
>> Hi Rafael,
>>
>> On 8/6/26 13:01, Daniel Lezcano wrote:
>>> Powercap controllers frequently expose a hierarchy of power zones (for
>>> example package, clusters and CPUs). Until now, each driver had to
>>> implement its own hierarchy traversal, parent lookup, error handling and
>>> teardown logic.
>>>
>>> This series introduces a generic hierarchy description and helper
>>> functions allowing a controller to instantiate and destroy an entire
>>> powercap hierarchy from a static description. The framework takes 
>>> care of
>>> duplicating the hierarchy description, rebasing parent pointers,
>>> creating zones in dependency order and performing the appropriate
>>> rollback and cleanup on errors.
>>>
>>> The series also adds a kselftest exercising the new API by creating a
>>> synthetic hierarchy, validating the exported sysfs hierarchy and
>>> attributes, and ensuring that all resources are correctly released when
>>> the hierarchy is destroyed.
>>>
>>> The patches are organized as follows:
>>>
>>> 1. powercap: Add generic zone hierarchy creation helpers
>>> 2. selftests/powercap: Add powercap hierarchy creation API tests
>>>
>>> The API was primarily motivated by the recently posted SPEL series and
>>> also provides a migration path for DTPM to use the same generic
>>> infrastructure instead of maintaining its own hierarchy handling.
>>>
>>> Link: SPEL cover letter <https://lore.kernel.org/lkml/20260702- 
>>> qcom_spel_driver_upstream-v3-0-434d50f0c5b0@oss.qualcomm.com/>
>>>
>>> Daniel Lezcano (2):
>>> powercap: Add generic zone hierarchy creation helpers
>>> selftests/powercap: Add powercap hierarchy creation API tests
>>>
>>> -- 
>> It was easy to migrate DTPM to this API and AFAICT Manaf was able to 
>> migrate also its series to this new API.
>>
>> Is it possible to consider it for merging ?
> 
> I will do a review for this patch set today...
> 
> I can see some potential improvements there.
This patch is a blocker for more changes: DTPM, powercap cooling device 
and SPEL drivers from Manaf.

It has been tested and there is a selftest with. Is it possible to 
consider these two patches for merging.

Given it is not a fast path, improvements can be proposed later.

Hi,

On 9/15/26 12:54, Daniel Lezcano wrote:

[ ... ]

>> I can see some potential improvements there.
> This patch is a blocker for more changes: DTPM, powercap cooling device 
> and SPEL drivers from Manaf.
> 
> It has been tested and there is a selftest with. Is it possible to 
> consider these two patches for merging.
> 
> Given it is not a fast path, improvements can be proposed later.


Given that there has been no feedback so far, would it be possible to 
consider merging these two patches? They are currently blocking further 
work.

There is also a selftest covering this functionality, so future changes 
can be made with regression testing in place.

Hi Daniel,

On Wed, Sep 23, 2026 at 3:47 PM Daniel Lezcano
<daniel.lezcano@oss.qualcomm.com> wrote:
>
>
> Hi,
>
> On 9/15/26 12:54, Daniel Lezcano wrote:
>
> [ ... ]
>
> >> I can see some potential improvements there.
> > This patch is a blocker for more changes: DTPM, powercap cooling device
> > and SPEL drivers from Manaf.
> >
> > It has been tested and there is a selftest with. Is it possible to
> > consider these two patches for merging.
> >
> > Given it is not a fast path, improvements can be proposed later.
>
>
> Given that there has been no feedback so far, would it be possible to
> consider merging these two patches? They are currently blocking further
> work.
>
> There is also a selftest covering this functionality, so future changes
> can be made with regression testing in place.

I'd prefer to handle this along with

https://lore.kernel.org/linux-pm/20260819165605.1398880-1-daniel.lezcano@oss.qualcomm.com/

which appears to be the only user of it.

I thought that Lukasz would send comments on those, but in the absence
of his comments, it would help if you combined those two patch series
into one and resend.

Thanks!

On 9/23/26 15:58, Rafael J. Wysocki (Intel) wrote:
> Hi Daniel,
> 
> On Wed, Sep 23, 2026 at 3:47 PM Daniel Lezcano
> <daniel.lezcano@oss.qualcomm.com> wrote:
>>
>>
>> Hi,
>>
>> On 9/15/26 12:54, Daniel Lezcano wrote:
>>
>> [ ... ]
>>
>>>> I can see some potential improvements there.
>>> This patch is a blocker for more changes: DTPM, powercap cooling device
>>> and SPEL drivers from Manaf.
>>>
>>> It has been tested and there is a selftest with. Is it possible to
>>> consider these two patches for merging.
>>>
>>> Given it is not a fast path, improvements can be proposed later.
>>
>>
>> Given that there has been no feedback so far, would it be possible to
>> consider merging these two patches? They are currently blocking further
>> work.
>>
>> There is also a selftest covering this functionality, so future changes
>> can be made with regression testing in place.
> 
> I'd prefer to handle this along with
> 
> https://lore.kernel.org/linux-pm/20260819165605.1398880-1-daniel.lezcano@oss.qualcomm.com/
> 
> which appears to be the only user of it.
> 
> I thought that Lukasz would send comments on those, but in the absence
> of his comments, it would help if you combined those two patch series
> into one and resend.
Sure, will do