All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexandre Bailon <abailon@baylibre.com>
To: Daniel Lezcano <daniel.lezcano@linaro.org>,
	rui.zhang@intel.com, amitk@kernel.org
Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
	ben.tseng@mediatek.com, khilman@baylibre.com, mka@chromium.org
Subject: Re: [PATCH v2 0/2] Add a generic virtual thermal sensor
Date: Mon, 4 Oct 2021 12:24:21 +0200	[thread overview]
Message-ID: <4446577e-c7fa-daeb-e0fe-8a530633ef5d@baylibre.com> (raw)
In-Reply-To: <794e62ea-d867-3827-de5f-24ddc86c3524@linaro.org>


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

>

  reply	other threads:[~2021-10-04 10:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-17  7:27 [PATCH v2 0/2] Add a generic virtual thermal sensor Alexandre Bailon
2021-09-17  7:27 ` [PATCH v2 1/2] dt-bindings: Add bindings for the " Alexandre Bailon
2021-09-17  7:27 ` [PATCH v2 2/2] thermal: add a virtual sensor to aggregate temperatures Alexandre Bailon
2021-10-07 16:38   ` Rafael J. Wysocki
2021-10-07 17:33     ` Rafael J. Wysocki
2021-10-09 14:46     ` Rafael J. Wysocki
2021-10-25  9:18     ` Alexandre Bailon
2021-09-17 12:41 ` [PATCH v2 0/2] Add a generic virtual thermal sensor Daniel Lezcano
2021-09-17 13:33   ` Alexandre Bailon
2021-09-17 14:03     ` Daniel Lezcano
2021-09-20 13:12       ` Alexandre Bailon
2021-09-22  8:10         ` Daniel Lezcano
2021-10-04 10:24           ` Alexandre Bailon [this message]
2021-10-04 13:42             ` Daniel Lezcano
2021-10-05 16:45               ` Rafael J. Wysocki
2021-10-06 16:06                 ` Daniel Lezcano
2021-10-06 18:00                   ` Rafael J. Wysocki
2021-10-06 19:51                     ` Daniel Lezcano
2021-10-07 14:17                       ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4446577e-c7fa-daeb-e0fe-8a530633ef5d@baylibre.com \
    --to=abailon@baylibre.com \
    --cc=amitk@kernel.org \
    --cc=ben.tseng@mediatek.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=khilman@baylibre.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mka@chromium.org \
    --cc=rui.zhang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.