This series cleans up the lifetime handling of thermal devices.

Currently, the thermal class release callback handles both thermal
zones and cooling devices by checking the device name prefix. This
approach is fragile and mixes responsibilities across different object
types.

The first two patches introduce dedicated struct device release
callbacks for thermal zones and cooling devices. This removes the need
to rely on device names and keeps the lifetime management local to
each object.

The last two patches convert the thermal class to a dynamically
allocated object and simplify the initialization logic by using the
class pointer itself as a guard instead of a separate boolean flag.

Overall, this results in a clearer separation of responsibilities and
more robust lifetime management aligned with the device model.

No functional change intended.

---

Daniel Lezcano (4):
  thermal/core: Add dedicated release callback for cooling devices
  thermal/core: Add dedicated release callback for thermal zones
  thermal/core: Allocate the thermal class dynamically
  thermal/core: Use the thermal class pointer as init guard

 drivers/thermal/thermal_core.c | 73 ++++++++++++++++------------------
 1 file changed, 35 insertions(+), 38 deletions(-)

-- 
2.43.0

On 5/8/26 20:05, Daniel Lezcano wrote:
> This series cleans up the lifetime handling of thermal devices.
> 
> Currently, the thermal class release callback handles both thermal
> zones and cooling devices by checking the device name prefix. This
> approach is fragile and mixes responsibilities across different object
> types.
> 
> The first two patches introduce dedicated struct device release
> callbacks for thermal zones and cooling devices. This removes the need
> to rely on device names and keeps the lifetime management local to
> each object.
> 
> The last two patches convert the thermal class to a dynamically
> allocated object and simplify the initialization logic by using the
> class pointer itself as a guard instead of a separate boolean flag.
> 
> Overall, this results in a clearer separation of responsibilities and
> more robust lifetime management aligned with the device model.
> 
> No functional change intended.
Unless I’m mistaken, the patch sent to split the cooling device 
registration is correct with this cleanup.

Hi Rafael,

On 5/8/26 20:10, Daniel Lezcano wrote:
> On 5/8/26 20:05, Daniel Lezcano wrote:
>> This series cleans up the lifetime handling of thermal devices.
>>
>> Currently, the thermal class release callback handles both thermal
>> zones and cooling devices by checking the device name prefix. This
>> approach is fragile and mixes responsibilities across different object
>> types.
>>
>> The first two patches introduce dedicated struct device release
>> callbacks for thermal zones and cooling devices. This removes the need
>> to rely on device names and keeps the lifetime management local to
>> each object.
>>
>> The last two patches convert the thermal class to a dynamically
>> allocated object and simplify the initialization logic by using the
>> class pointer itself as a guard instead of a separate boolean flag.
>>
>> Overall, this results in a clearer separation of responsibilities and
>> more robust lifetime management aligned with the device model.
>>
>> No functional change intended.
> Unless I’m mistaken, the patch sent to split the cooling device 
> registration is correct with this cleanup.

Were you able to apply the patch splitting the cooling device 
registration on top of this series ?

On Wed, May 13, 2026 at 4:22 PM Daniel Lezcano
<daniel.lezcano@oss.qualcomm.com> wrote:
>
>
> Hi Rafael,
>
> On 5/8/26 20:10, Daniel Lezcano wrote:
> > On 5/8/26 20:05, Daniel Lezcano wrote:
> >> This series cleans up the lifetime handling of thermal devices.
> >>
> >> Currently, the thermal class release callback handles both thermal
> >> zones and cooling devices by checking the device name prefix. This
> >> approach is fragile and mixes responsibilities across different object
> >> types.
> >>
> >> The first two patches introduce dedicated struct device release
> >> callbacks for thermal zones and cooling devices. This removes the need
> >> to rely on device names and keeps the lifetime management local to
> >> each object.
> >>
> >> The last two patches convert the thermal class to a dynamically
> >> allocated object and simplify the initialization logic by using the
> >> class pointer itself as a guard instead of a separate boolean flag.
> >>
> >> Overall, this results in a clearer separation of responsibilities and
> >> more robust lifetime management aligned with the device model.
> >>
> >> No functional change intended.
> > Unless I’m mistaken, the patch sent to split the cooling device
> > registration is correct with this cleanup.
>
> Were you able to apply the patch splitting the cooling device
> registration on top of this series ?

I haven't tried that yet, but I'll do it later today.

On 5/13/26 16:06, Rafael J. Wysocki wrote:
> On Wed, May 13, 2026 at 4:22 PM Daniel Lezcano
> <daniel.lezcano@oss.qualcomm.com> wrote:
>>
>>
>> Hi Rafael,
>>
>> On 5/8/26 20:10, Daniel Lezcano wrote:
>>> On 5/8/26 20:05, Daniel Lezcano wrote:
>>>> This series cleans up the lifetime handling of thermal devices.
>>>>
>>>> Currently, the thermal class release callback handles both thermal
>>>> zones and cooling devices by checking the device name prefix. This
>>>> approach is fragile and mixes responsibilities across different object
>>>> types.
>>>>
>>>> The first two patches introduce dedicated struct device release
>>>> callbacks for thermal zones and cooling devices. This removes the need
>>>> to rely on device names and keeps the lifetime management local to
>>>> each object.
>>>>
>>>> The last two patches convert the thermal class to a dynamically
>>>> allocated object and simplify the initialization logic by using the
>>>> class pointer itself as a guard instead of a separate boolean flag.
>>>>
>>>> Overall, this results in a clearer separation of responsibilities and
>>>> more robust lifetime management aligned with the device model.
>>>>
>>>> No functional change intended.
>>> Unless I’m mistaken, the patch sent to split the cooling device
>>> registration is correct with this cleanup.
>>
>> Were you able to apply the patch splitting the cooling device
>> registration on top of this series ?
> 
> I haven't tried that yet, but I'll do it later today.

Just to double check, we are talking about this patch (that we discussed
back then):

https://lore.kernel.org/lkml/20260505144447.2853933-1-daniel.lezcano@oss.qualcomm.com/

With the re-work done here, I can put my review tag into
that patch. The error handling paths there should be safe now.

On 5/13/26 17:45, Lukasz Luba wrote:
> 
> 
> On 5/13/26 16:06, Rafael J. Wysocki wrote:
>> On Wed, May 13, 2026 at 4:22 PM Daniel Lezcano
>> <daniel.lezcano@oss.qualcomm.com> wrote:
>>>
>>>
>>> Hi Rafael,
>>>
>>> On 5/8/26 20:10, Daniel Lezcano wrote:
>>>> On 5/8/26 20:05, Daniel Lezcano wrote:
>>>>> This series cleans up the lifetime handling of thermal devices.
>>>>>
>>>>> Currently, the thermal class release callback handles both thermal
>>>>> zones and cooling devices by checking the device name prefix. This
>>>>> approach is fragile and mixes responsibilities across different object
>>>>> types.
>>>>>
>>>>> The first two patches introduce dedicated struct device release
>>>>> callbacks for thermal zones and cooling devices. This removes the need
>>>>> to rely on device names and keeps the lifetime management local to
>>>>> each object.
>>>>>
>>>>> The last two patches convert the thermal class to a dynamically
>>>>> allocated object and simplify the initialization logic by using the
>>>>> class pointer itself as a guard instead of a separate boolean flag.
>>>>>
>>>>> Overall, this results in a clearer separation of responsibilities and
>>>>> more robust lifetime management aligned with the device model.
>>>>>
>>>>> No functional change intended.
>>>> Unless I’m mistaken, the patch sent to split the cooling device
>>>> registration is correct with this cleanup.
>>>
>>> Were you able to apply the patch splitting the cooling device
>>> registration on top of this series ?
>>
>> I haven't tried that yet, but I'll do it later today.
> 
> Just to double check, we are talking about this patch (that we discussed
> back then):
> 
> https://lore.kernel.org/lkml/20260505144447.2853933-1- 
> daniel.lezcano@oss.qualcomm.com/

Yes, I'm just wondering if it applies as is

> With the re-work done here, I can put my review tag into
> that patch. The error handling paths there should be safe now.

Great, thanks for your review