[PATCH v2 06/16] thermal: Don't use 'device' internal thermal zone structure field
Daniel Lezcano
daniel.lezcano at linaro.org
Thu Feb 23 06:35:56 PST 2023
On 23/02/2023 12:43, Rafael J. Wysocki wrote:
> On Thu, Feb 23, 2023 at 10:56 AM Daniel Lezcano
> <daniel.lezcano at linaro.org> wrote:
>>
>> On 22/02/2023 21:06, Rafael J. Wysocki wrote:
>>> On Wed, Feb 22, 2023 at 9:00 PM Daniel Lezcano
>>> <daniel.lezcano at linaro.org> wrote:
>>>>
>>>> On 22/02/2023 20:43, Rafael J. Wysocki wrote:
>>>>> On Tue, Feb 21, 2023 at 7:07 PM Daniel Lezcano
>>>>> <daniel.lezcano at linaro.org> wrote:
>>>>>>
>>>>>> Some drivers are directly using the thermal zone's 'device' structure
>>>>>> field.
>>>>>>
>>>>>> Use the driver device pointer instead of the thermal zone device when
>>>>>> it is available.
>>>>>>
>>>>>> Remove the traces when they are duplicate with the traces in the core
>>>>>> code.
>>>>>>
>>>>>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
>>>>>> Reviewed-by: Balsam CHIHI <bchihi at baylibre.com> #Mediatek LVTS
>>>>>> ---
>>>>
>>>> [ ... ]
>>>>
>>>>>> thermal_zone_device_update(data->ti_thermal, THERMAL_EVENT_UNSPECIFIED);
>>>>>>
>>>>>> - dev_dbg(&data->ti_thermal->device, "updated thermal zone %s\n",
>>>>>> + dev_dbg(data->bgp->dev, "updated thermal zone %s\n",
>>>>>> data->ti_thermal->type);
>>>>>
>>>>> The code before the change is more consistent, because it refers to
>>>>> the same object in both instances.
>>>>>
>>>>> It looks like a type field accessor is needed, eg. thermal_zone_device_type()?
>>>>>
>>>>> Or move the debug message to thermal_zone_device_update()?
>>>>
>>>> Actually it is done on purpose because the patch 9 replaces the accesses
>>>> to 'type' by 'id', the thermal_zone_device_type() accessor won't be needed.
>>>
>>> Cool.
>>>
>>> However, this is a change in behavior (albeit small) which doesn't
>>> appear to be necessary.
>>>
>>> What would be wrong with having a tz->type accessor too?
>>
>> I can add the 'type' accessor but from my point of view it is not
>> correct because the information belongs to the thermal framework and it
>> is used to export the information in the sysfs which is along with the
>> directory name giving the id of the thermal zone.
>
> I'm not sure what you mean here.
>
> Surely, the 'type' is provided by whoever registers the thermal zone,
> so I'm not sure in what way it "belongs" to the framework.
I meant the goal of 'type' is to be exported to sysfs, nothing else.
That is the reason why I used the word 'belongs', because it was
introduced to stay in the scope of the thermal framework, but then its
usage has been diverted to a name.
Anyway, from my POV having traces in the ops is not a good thing, so
I'll propose later to remove them and add a single message in the call
sites.
Meanwhile, I'll provide the accessor for 'type' and hopefully we do not
end up with a plethora of accessors to be used in the core code.
--
<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
More information about the Linux-mediatek
mailing list