linux-kernel - Re: [PATCH v2 0/2] Add a generic virtual thermal sensor

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: <4446577e-c7fa-daeb-e0fe-8a530633ef5d@baylibre.com>
Date:   Mon, 4 Oct 2021 12:24:21 +0200
From:   Alexandre Bailon <abailon@...libre.com>
To:     Daniel Lezcano <daniel.lezcano@...aro.org>, rui.zhang@...el.com,
        amitk@...nel.org
Cc:     linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        ben.tseng@...iatek.com, khilman@...libre.com, mka@...omium.org
Subject: Re: [PATCH v2 0/2] Add a generic virtual thermal sensor


On 9/22/21 10:10 AM, Daniel Lezcano wrote:
> On 20/09/2021 15:12, Alexandre Bailon wrote:
>> On 9/17/21 4:03 PM, Daniel Lezcano wrote:
>>> On 17/09/2021 15:33, Alexandre Bailon wrote:
>>>> Hi Daniel,
>>>>
>>>> On 9/17/21 2:41 PM, Daniel Lezcano wrote:
>>>>> On 17/09/2021 09:27, Alexandre Bailon wrote:
>>>>>> This series add a virtual thermal sensor.
>>>>>> It could be used to get a temperature using some thermal sensors.
>>>>>> Currently, the supported operations are max, min and avg.
>>>>>> The virtual sensor could be easily extended to support others
>>>>>> operations.
>>>>>>
>>>>>> Note:
>>>>>> Currently, thermal drivers must explicitly register their sensors to
>>>>>> make them
>>>>>> available to the virtual sensor.
>>>>>> This doesn't seem a good solution to me and I think it would be
>>>>>> preferable to
>>>>>> update the framework to register the list of each available sensors.
>>>>> Why must the drivers do that ?
>>>> Because there are no central place where thermal sensor are registered.
>>>> The only other way I found was to update thermal_of.c,
>>>> to register the thermal sensors and make them available later to the
>>>> virtual thermal sensor.
>>>>
>>>> To work, the virtual thermal need to get the sensor_data the ops from
>>>> the thermal sensor.
>>>> And as far I know, this is only registered in thermal_of.c, in the
>>>> thermal zone data
>>>> but I can't access it directly from the virtual thermal sensor.
>>>>
>>>> How would you do it ?
>>> Via the phandles when registering the virtual sensor ?
>> As far I know, we can't get the ops or the sensor_data from the phandle
>> of a thermal sensor.
>> The closest solution I found so far would be to aggregate the thermal
>> zones instead of thermal sensors.
>> thermal_zone_device has the data needed and a thermal zone could be find
>> easily using its name.
> Yeah, the concept of the thermal zone and the sensor are very close.
>
> There is the function in thermal_core.h:
>
>   -> for_each_thermal_zone()
>
> You should be able for each 'slave' sensor, do a lookup to find the
> corresponding thermal_zone_device_ops.
>
>> But, using a thermal_zone_device, I don't see how to handle module
>> unloading.
> I think try_module_get() / module_put() are adequate for this situation
> as it is done on an external module and we can not rely on the exported
> symbols.
I don't see how it would be possible to use these functions.
The thermal zone doesn't have the data required to use it.

Maybe a more easier way is to use the thermal_zone_device mutex.
If I get a lock before to use the thermal_zone_device ops, I have the 
guaranty that module won't be unloaded.

When a "thermal of sensor" is unloaded, it calls 
thermal_zone_of_sensor_unregister which takes a lock before
update ops.

Thanks,
Alexandre

>