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: <794e62ea-d867-3827-de5f-24ddc86c3524@linaro.org>
Date:   Wed, 22 Sep 2021 10:10:29 +0200
From:   Daniel Lezcano <daniel.lezcano@...aro.org>
To:     Alexandre Bailon <abailon@...libre.com>, 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 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.


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog