linux-kernel - Re: [PATCH v2 06/16] thermal: Don't use 'device' internal thermal zone structure field

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 23 Feb 2023 12:43:00 +0100
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Daniel Lezcano <daniel.lezcano@...aro.org>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org, Balsam CHIHI <bchihi@...libre.com>,
        Amit Kucheria <amitk@...nel.org>,
        Zhang Rui <rui.zhang@...el.com>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        Eduardo Valentin <edubezval@...il.com>,
        Keerthy <j-keerthy@...com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        Ido Schimmel <idosch@...dia.com>,
        Mark Brown <broonie@...nel.org>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>,
        "open list:TI BANDGAP AND THERMAL DRIVER" 
        <linux-omap@...r.kernel.org>,
        "moderated list:ARM/Mediatek SoC support" 
        <linux-mediatek@...ts.infradead.org>
Subject: Re: [PATCH v2 06/16] thermal: Don't use 'device' internal thermal
 zone structure field

On Thu, Feb 23, 2023 at 10:56 AM Daniel Lezcano
<daniel.lezcano@...aro.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@...aro.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@...aro.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@...aro.org>
> >>>> Reviewed-by: Balsam CHIHI <bchihi@...libre.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.

> Actually, the useful information is the id of the thermal zone, not the
> type. This one can be duplicate, for instance:
>
> cat /sys/class/thermal/thermal_zone*/type
> acpitz
> acpitz

That's correct, but in the particular case of DT-based systems it
comes from the DT (AFAICT) and so it allows to connect the kernel
message with the DT contents.  The id could be used for that, but that
involves an extra sysfs lookup.

> Given there are few places where 'type' is used in the drivers, I prefer
> to directly change that to 'id' in the next patch instead of creating
> the accessor for 'type', then send another series removing it.

So you are going to change the behavior of those few places with the
only reason being aesthetics AFAICS.  Is this really a good enough
reason to do that?