On Thu, Nov 20, 2025 at 4:41 AM Armin Wolf <[email protected]> wrote: > > Drivers registering thermal zone/cooling devices are currently unable > to tell the thermal core what parent device the new thermal zone/ > cooling device should have, potentially causing issues with suspend > ordering
This is one potential class of problems that may arise, but I would like to see a real example of this. As it stands today, thermal_class has no PM callbacks, so there are no callback execution ordering issues with devices in that class and what other suspend/resume ordering issues are there? Also, the suspend and resume of thermal zones is handled via PM notifiers. Is there a problem with this? > and making it impossible for user space applications to > associate a given thermal zone device with its parent device. Why does user space need to know the parent of a given cooling device or thermal zone? > This patch series aims to fix this issue by extending the functions > used to register thermal zone/cooling devices to also accept a parent > device pointer. The first six patches convert all functions used for > registering cooling devices, while the functions used for registering > thermal zone devices are converted by the remaining two patches. > > I tested this series on various devices containing (among others): > - ACPI thermal zones > - ACPI processor devices > - PCIe cooling devices > - Intel Wifi card > - Intel powerclamp > - Intel TCC cooling What exactly did you do to test it? > I also compile-tested the remaining affected drivers, however i would > still be happy if the relevant maintainers (especially those of the > mellanox ethernet switch driver) could take a quick glance at the > code and verify that i am using the correct device as the parent > device. I think that the above paragraph is not relevant any more? > This work is also necessary for extending the ACPI thermal zone driver > to support the _TZD ACPI object in the future. I'm still unsure why _TZD support requires the ability to set a thermal zone parent device. > Signed-off-by: Armin Wolf <[email protected]> > --- > Armin Wolf (8): > thermal: core: Allow setting the parent device of cooling devices > thermal: core: Set parent device in thermal_of_cooling_device_register() > ACPI: processor: Stop creating "device" sysfs link That link is not to the cooling devices' parent, but to the ACPI device object (a struct acpi_device) that corresponds to the parent. The parent of the cooling device should be the processor device, not its ACPI companion, so I'm not sure why there would be a conflict. > ACPI: fan: Stop creating "device" sysfs link > ACPI: video: Stop creating "device" sysfs link Analogously in the above two cases AFAICS. The parent of a cooling device should be a "physical" device object, like a platform device or a PCI device or similar, not a struct acpi_device (which in fact is not a device even). > thermal: core: Set parent device in thermal_cooling_device_register() > ACPI: thermal: Stop creating "device" sysfs link And this link is to the struct acpi_device representing the thermal zone itself. > thermal: core: Allow setting the parent device of thermal zone devices I'm not sure if this is a good idea, at least until it is clear what the role of a thermal zone parent device should be.
