mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: rui.zhang@intel.com, linux-kernel@vger.kernel.org,
	linux-pm@vger.kernel.org, Amit Kucheria <amitk@kernel.org>
Subject: Re: [PATCH v2 2/7] thermal/core: Encapsulate tz->device field
Date: Wed, 12 Apr 2023 21:17:02 +0200	[thread overview]
Message-ID: <cac6faa7-91ac-1fbb-8cdf-670422585cfc@linaro.org> (raw)
In-Reply-To: <CAJZ5v0i65XivddWvP9OSuXePwbeWYsgtOr_GB=BBN_jwsWarjQ@mail.gmail.com>

On 12/04/2023 20:56, Rafael J. Wysocki wrote:
> On Tue, Apr 11, 2023 at 10:20 PM Daniel Lezcano
> <daniel.lezcano@linaro.org> wrote:
>>
>> On 11/04/2023 20:19, Rafael J. Wysocki wrote:
>>> On Mon, Apr 10, 2023 at 10:53 PM Daniel Lezcano
>>> <daniel.lezcano@linaro.org> wrote:
>>>>
>>>> There are still some drivers needing to play with the thermal zone
>>>> device internals. That is not the best but until we can figure out if
>>>> the information is really needed, let's encapsulate the field used in
>>>> the thermal zone device structure, so we can move forward relocating
>>>> the thermal zone device structure definition in the thermal framework
>>>> private headers.
>>>
>>> I'm not really sure why this is needed, so please explain.
>>
>> Some drivers are accessing tz->device, that implies they have the
>> knowledge of the thermal_zone_device structure but we want to
>> self-encapsulate this structure and reduce the scope of the structure to
>> the thermal core only.
>>
>> The ACPI and the Menlon drivers are the drivers accessing tz->device.
>>
>> By adding this wrapper, these drivers do no longer need the thermal zone
>> device structure definition.
> 
> So you want to move the definition of struct thermal_zone_device from
> include/linux/thermal.h into a local header in drivers/thermal/ and
> make it entirely local to the thermal core IIUC.
> 
> Which would be forcing the callers of
> thermal_zone_device_register_with_trips() (and friends) to use
> pointers to a data type that's not completely defined (from their
> perspective), but they would still have access to the trips array
> passed to that function.
> 
> That doesn't sound particularly consistent and what's the purpose of doing it?
The first thing is prevent drivers tampering with the thermal core 
structure internals, so moving the structures from 
include/linux/thermal.h to drivers/thermal/thermal_core.h is one step to 
this direction.

As you point it, drivers can still do things with the trip arrays passed 
as parameter. For that the idea is to do the same as:

https://lore.kernel.org/all/20230404075138.2914680-3-daniel.lezcano@linaro.org/

So the array is an initialization data and it will stay private to the 
thermal core code.

In order to update the trip points, we add a 
thermal_zone_device_trips_update() function which does a kmemdup, 
pointer switch, kfree of the previous trips and a notification.

I addressed that in response to your ACPI series questions:

https://lore.kernel.org/all/38a5a6e0-2af8-8365-b20e-8494a4efcb0c@linaro.org/

Does it make sense with this additional information ?


>>>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>>>> ---
>>>>    drivers/thermal/thermal_core.c | 6 ++++++
>>>>    include/linux/thermal.h        | 1 +
>>>>    2 files changed, 7 insertions(+)
>>>>
>>>> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
>>>> index c5025aca22ee..842f678c1c3e 100644
>>>> --- a/drivers/thermal/thermal_core.c
>>>> +++ b/drivers/thermal/thermal_core.c
>>>> @@ -1398,6 +1398,12 @@ int thermal_zone_device_id(struct thermal_zone_device *tzd)
>>>>    }
>>>>    EXPORT_SYMBOL_GPL(thermal_zone_device_id);
>>>>
>>>> +struct device *thermal_zone_device(struct thermal_zone_device *tzd)
>>>> +{
>>>> +       return &tzd->device;
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(thermal_zone_device);
>>>> +
>>>>    /**
>>>>     * thermal_zone_device_unregister - removes the registered thermal zone device
>>>>     * @tz: the thermal zone device to remove
>>>> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
>>>> index 82ddb32f9876..87837094d549 100644
>>>> --- a/include/linux/thermal.h
>>>> +++ b/include/linux/thermal.h
>>>> @@ -313,6 +313,7 @@ thermal_zone_device_register_with_trips(const char *, struct thermal_trip *, int
>>>>    void *thermal_zone_device_priv(struct thermal_zone_device *tzd);
>>>>    const char *thermal_zone_device_type(struct thermal_zone_device *tzd);
>>>>    int thermal_zone_device_id(struct thermal_zone_device *tzd);
>>>> +struct device *thermal_zone_device(struct thermal_zone_device *tzd);
>>>>
>>>>    int thermal_zone_bind_cooling_device(struct thermal_zone_device *, int,
>>>>                                        struct thermal_cooling_device *,
>>>> --
>>>> 2.34.1
>>>>
>>
>> --
>> <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
>>

-- 
<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


  reply	other threads:[~2023-04-12 19:17 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-10 20:52 [PATCH v2 0/7] Thermal zone device structure encapsulation Daniel Lezcano
2023-04-10 20:52 ` [PATCH v2 1/7] thermal/drivers/intel_pch_thermal: Use thermal driver device to write a trace Daniel Lezcano
2023-04-11 18:16   ` Rafael J. Wysocki
2023-04-11 20:10     ` Daniel Lezcano
2023-04-12 18:35       ` Rafael J. Wysocki
2023-04-10 20:53 ` [PATCH v2 2/7] thermal/core: Encapsulate tz->device field Daniel Lezcano
2023-04-11 18:19   ` Rafael J. Wysocki
2023-04-11 20:20     ` Daniel Lezcano
2023-04-12 18:56       ` Rafael J. Wysocki
2023-04-12 19:17         ` Daniel Lezcano [this message]
2023-04-10 20:53 ` [PATCH v2 3/7] thermal/drivers/acpi: Use thermal_zone_device() Daniel Lezcano
2023-04-10 20:53 ` [PATCH v2 4/7] thermal/drivers/menlow: " Daniel Lezcano
2023-04-10 20:53 ` [PATCH v2 5/7] thermal/core: Prepare sanitizing thermal class sysfs content Daniel Lezcano
2023-04-11 18:23   ` Rafael J. Wysocki
2023-04-10 20:53 ` [PATCH v2 6/7] thermal/drivers/acpi: Make cross dev link optional by configuration Daniel Lezcano
2023-04-11 18:26   ` Rafael J. Wysocki
2023-04-11 20:21     ` Daniel Lezcano
2023-04-10 20:53 ` [PATCH v2 7/7] thermal/drivers/intel_menlow: Make additionnal sysfs information optional Daniel Lezcano

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=cac6faa7-91ac-1fbb-8cdf-670422585cfc@linaro.org \
    --to=daniel.lezcano@linaro.org \
    --cc=amitk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rafael@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®