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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <920f8285-1b49-d088-64b4-98bce8d23e39@collabora.com>
Date:   Mon, 20 Apr 2020 20:19:43 +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

@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