Re: [RFC v3 1/2] thermal: core: Let thermal zone device's mode be stored in its struct
From: Andrzej Pietrasiewicz <hidden>
Date: 2020-04-20 18:19:57
Also in:
linux-acpi, linux-arm-kernel, linux-pm, platform-driver-x86
@Daniel please see below W dniu 20.04.2020 o 13:03, Andrzej Pietrasiewicz pisze:
Hi Barlomiej, Thanks for looking into the series. @Daniel can you see below? W dniu 19.04.2020 o 13:38, Bartlomiej Zolnierkiewicz pisze:quoted
Hi Andrzej, On 4/17/20 6:20 PM, Andrzej Pietrasiewicz wrote:quoted
Thermal zone devices' mode is stored in individual drivers. This patch changes it so that mode is stored in struct thermal_zone_device instead. As a result all driver-specific variables storing the mode are not needed and are removed. Consequently, the get_mode() implementations have nothing to operate on and need to be removed, too. Some thermal framework specific functions are introduced: thermal_zone_device_get_mode() thermal_zone_device_set_mode() thermal_zone_device_enable() thermal_zone_device_disable() thermal_zone_device_get_mode() and its "set" counterpart take tzd's lock and the "set" calls driver's set_mode() if provided, so the latter must not take this lock again. At the end of the "set" thermal_zone_device_update() is called so drivers don't need to repeat this invocation in their specific set_mode() implementations. The scope of the above 4 functions is purposedly limited to the thermal framework and drivers are not supposed to call them. This encapsulationThis should be true only for thermal_zone_device_{get,set}_mode(). thermal_zone_device_{en,dis}able() should be available for device drivers: * of/thermal device drivers need to enable thermal device itself (please refer to my patchset for details) * device drivers need to call them on ->suspend and ->resume operations@Daniel: How does this compare to "Just: thermal_zone_device_get_mode() thermal_zone_device_set_mode() thermal_zone_device_disable() thermal_zone_device_enable() And all of them in drivers/thermal/thermal_core.h". Did I understand you correctly?
I sent a PATCH series (rather than next iteration of RFC) addressing Bartlomiej's comments. They make sense to me. Regards, Andrzej