[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4cda3e11-7bea-8445-cd51-4b25dcafc741@collabora.com>
Date: Mon, 20 Apr 2020 13:03:02 +0200
From: Andrzej Pietrasiewicz <andrzej.p@...labora.com>
To: Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
Cc: linux-pm@...r.kernel.org, Zhang Rui <rui.zhang@...el.com>,
"Rafael J . Wysocki" <rjw@...ysocki.net>,
Len Brown <lenb@...nel.org>, Jiri Pirko <jiri@...lanox.com>,
Ido Schimmel <idosch@...lanox.com>,
"David S . Miller" <davem@...emloft.net>,
Peter Kaestle <peter@...e.net>,
Darren Hart <dvhart@...radead.org>,
Andy Shevchenko <andy@...radead.org>,
Support Opensource <support.opensource@...semi.com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Amit Kucheria <amit.kucheria@...durent.com>,
Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Fabio Estevam <festevam@...il.com>,
NXP Linux Team <linux-imx@....com>,
Allison Randal <allison@...utok.net>,
Enrico Weigelt <info@...ux.net>,
Gayatri Kammela <gayatri.kammela@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
linux-acpi@...r.kernel.org, netdev@...r.kernel.org,
platform-driver-x86@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, kernel@...labora.com
Subject: Re: [RFC v3 1/2] thermal: core: Let thermal zone device's mode be
stored in its struct
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?
Andrzej
Powered by blists - more mailing lists