[RFC,00/26] Add thermal zones names and new registration func

  ** This RFC was sent only to thermal API maintainers + reviewers on purpose **

As per previous discussion with Daniel [1], I've prepared this series adding
a new struct thermal_zone_device_params, used in a new registration function
for thermal zones thermal_zone_device_register(), deprecating and, finally,
replacing functions thermal_tripless_zone_device_register() and
thermal_zone_device_register_with_trips().

The new flow to register a thermal zone becomes the following:
 - Declare a struct thermal_zone_device_params (`tzp` in this example)
 - Fill in all the params (instead of passing all of them to a function)
 - Call thermal_zone_device_register(tzp)

Moreover, I've also introduced the concept of `name` for a thermal zone,
and set, as suggested, a constraint for which:
 - Multiple thermal zones can have the same `type` (so, no change), and
 - A thermal zone's name must be *unique*.

This should then help (in a later series?) to disambiguate thermal zone
name vs type, as most of (if not all) the users seem to actually be
misusing the TZ type referring to / using it as a TZ name.

Please note that this series is currently a RFC because it's apparently
growing bigger than I wanted - and because I probably have to add some
more code on top. Before doing so, I'm trying to get feedback on what
I've done until now.

P.S.: I know, there's a fixup commit in the mix, will obviously fix
that for v1 :-)

[1]: https://lore.kernel.org/all/20231115144857.424005-1-angelogioacchino.delregno@collabora.com/

AngeloGioacchino Del Regno (26):
  thermal: Introduce thermal_zone_device_register() and params structure
  thermal/of: Migrate to thermal_zone_device_register()
  platform/x86: acerhdf: Migrate to thermal_zone_device_register()
  ACPI: thermal: Migrate to thermal_zone_device_register()
  thermal/drivers/da9062: Migrate to thermal_zone_device_register()
  thermal/drivers/imx: Migrate to thermal_zone_device_register()
  thermal/drivers/rcar: Migrate to thermal_zone_device_register()
  thermal/drivers/st: Migrate to thermal_zone_device_register()
  thermal: intel: pch_thermal: Migrate to thermal_zone_device_register()
  thermal: intel: quark_dts: Migrate to thermal_zone_device_register()
  thermal: intel: soc_dts_iosf: Migrate to
    thermal_zone_device_register()
  thermal: intel: int340x: Migrate to thermal_zone_device_register()
  thermal: int340x: processor: Migrate to thermal_zone_device_register()
  thermal: intel: x86_pkg_temp: Migrate to
    thermal_zone_device_register()
  power: supply: core: Migrate to thermal_zone_device_register()
  thermal/drivers/armada: Migrate to thermal_zone_device_register()
  thermal/drivers/dove: Migrate to thermal_zone_device_register()
  thermal/drivers/kirkwood: Migrate to thermal_zone_device_register()
  thermal/drivers/spear: Migrate to thermal_zone_device_register()
  thermal/drivers/int340x: Migrate to thermal_zone_device_register()
  wifi: iwlwifi: mvm: Migrate to thermal_zone_device_register()
  cxgb4: Migrate to thermal_zone_device_register()
  mlxsw: core_thermal: Migrate to thermal_zone_device_register()
  fixup! power: supply: core: Migrate to thermal_zone_device_register()
  thermal: Remove tripless_zone_register and register_with_trips
    functions
  thermal: Introduce thermal zones names

 drivers/acpi/thermal.c                        |  18 +--
 .../ethernet/chelsio/cxgb4/cxgb4_thermal.c    |  18 ++-
 .../ethernet/mellanox/mlxsw/core_thermal.c    |  93 +++++++-------
 drivers/net/wireless/intel/iwlwifi/mvm/tt.c   |  27 ++--
 drivers/platform/x86/acerhdf.c                |  25 ++--
 drivers/power/supply/power_supply_core.c      |  14 +-
 drivers/thermal/armada_thermal.c              |  10 +-
 drivers/thermal/da9062-thermal.c              |  14 +-
 drivers/thermal/dove_thermal.c                |   8 +-
 drivers/thermal/imx_thermal.c                 |  19 ++-
 .../intel/int340x_thermal/int3400_thermal.c   |  17 +--
 .../int340x_thermal/int340x_thermal_zone.c    |  28 ++--
 .../processor_thermal_device_pci.c            |  23 ++--
 drivers/thermal/intel/intel_pch_thermal.c     |  11 +-
 .../thermal/intel/intel_quark_dts_thermal.c   |  21 +--
 drivers/thermal/intel/intel_soc_dts_iosf.c    |  22 +++-
 drivers/thermal/intel/x86_pkg_temp_thermal.c  |  20 +--
 drivers/thermal/kirkwood_thermal.c            |   8 +-
 drivers/thermal/rcar_thermal.c                |  13 +-
 drivers/thermal/spear_thermal.c               |   8 +-
 drivers/thermal/st/st_thermal.c               |  15 ++-
 drivers/thermal/thermal_core.c                | 120 +++++++++---------
 drivers/thermal/thermal_of.c                  |  38 +++---
 drivers/thermal/thermal_sysfs.c               |   9 ++
 drivers/thermal/thermal_trace.h               |  17 ++-
 include/linux/thermal.h                       |  50 ++++++--
 26 files changed, 391 insertions(+), 275 deletions(-)
  

On Thu, Dec 21, 2023 at 1:48 PM AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com> wrote:
>
> ** This RFC was sent only to thermal API maintainers + reviewers on purpose **
>
> As per previous discussion with Daniel [1], I've prepared this series adding
> a new struct thermal_zone_device_params, used in a new registration function
> for thermal zones thermal_zone_device_register(), deprecating and, finally,
> replacing functions thermal_tripless_zone_device_register() and
> thermal_zone_device_register_with_trips().
>
> The new flow to register a thermal zone becomes the following:
>  - Declare a struct thermal_zone_device_params (`tzp` in this example)
>  - Fill in all the params (instead of passing all of them to a function)
>  - Call thermal_zone_device_register(tzp)
>
> Moreover, I've also introduced the concept of `name` for a thermal zone,
> and set, as suggested, a constraint for which:
>  - Multiple thermal zones can have the same `type` (so, no change), and
>  - A thermal zone's name must be *unique*.
>
> This should then help (in a later series?) to disambiguate thermal zone
> name vs type, as most of (if not all) the users seem to actually be
> misusing the TZ type referring to / using it as a TZ name.
>
> Please note that this series is currently a RFC because it's apparently
> growing bigger than I wanted - and because I probably have to add some
> more code on top. Before doing so, I'm trying to get feedback on what
> I've done until now.

And it is very unlikely that I will be able to provide any useful
feedback on this series before 6.8-rc1 is out.

Thanks!
  

Il 21/12/23 14:38, Rafael J. Wysocki ha scritto:
> On Thu, Dec 21, 2023 at 1:48 PM AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com> wrote:
>>
>> ** This RFC was sent only to thermal API maintainers + reviewers on purpose **
>>
>> As per previous discussion with Daniel [1], I've prepared this series adding
>> a new struct thermal_zone_device_params, used in a new registration function
>> for thermal zones thermal_zone_device_register(), deprecating and, finally,
>> replacing functions thermal_tripless_zone_device_register() and
>> thermal_zone_device_register_with_trips().
>>
>> The new flow to register a thermal zone becomes the following:
>>   - Declare a struct thermal_zone_device_params (`tzp` in this example)
>>   - Fill in all the params (instead of passing all of them to a function)
>>   - Call thermal_zone_device_register(tzp)
>>
>> Moreover, I've also introduced the concept of `name` for a thermal zone,
>> and set, as suggested, a constraint for which:
>>   - Multiple thermal zones can have the same `type` (so, no change), and
>>   - A thermal zone's name must be *unique*.
>>
>> This should then help (in a later series?) to disambiguate thermal zone
>> name vs type, as most of (if not all) the users seem to actually be
>> misusing the TZ type referring to / using it as a TZ name.
>>
>> Please note that this series is currently a RFC because it's apparently
>> growing bigger than I wanted - and because I probably have to add some
>> more code on top. Before doing so, I'm trying to get feedback on what
>> I've done until now.
> 
> And it is very unlikely that I will be able to provide any useful
> feedback on this series before 6.8-rc1 is out.
> 
> Thanks!

Thanks for telling - but hey, obviously there's no rush, please take your time.

Cheers!
Angelo