Re: [RFC v3 1/2] thermal: core: Let thermal zone device's mode be stored in its struct

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



@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:

Hi Andrzej,

On 4/17/20 6:20 PM, Andrzej Pietrasiewicz wrote:
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 encapsulation

This 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



[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux