linux-kernel - Re: [PATCH v4 3/4] thermal/core: Build ascending ordered indexes for the trip points

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: <CAJZ5v0gjfeyiS8rUoPpa3sMrofw1ZyQe=+P6pvPbeirs07F+Qw@mail.gmail.com>
Date:   Thu, 21 Jul 2022 13:25:53 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Daniel Lezcano <daniel.lezcano@...aro.org>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Manaf Meethalavalappu Pallikunhi <quic_manafm@...cinc.com>,
        "Zhang, Rui" <rui.zhang@...el.com>,
        Amit Kucheria <amitk@...nel.org>,
        Lukasz Luba <lukasz.luba@....com>,
        Linux PM <linux-pm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 3/4] thermal/core: Build ascending ordered indexes for
 the trip points

On Thu, Jul 21, 2022 at 12:59 PM Daniel Lezcano
<daniel.lezcano@...aro.org> wrote:
>
> On 19/07/2022 20:56, Rafael J. Wysocki wrote:
> > On Mon, Jul 18, 2022 at 4:50 PM Daniel Lezcano
> > <daniel.lezcano@...aro.org> wrote:
> >>
> >> By convention the trips points are declared in the ascending
> >> temperature order. However, no specification for the device tree, ACPI
> >> or documentation tells the trip points must be ordered this way.
> >>
> >> In the other hand, we need those to be ordered to browse them at the
> >
> > s/In/On/
> >
> >> thermal events.
> >
> > What if they are all inspected every time?
>
> My bad, my sentence is confusing. The trip point are browsed every time
> and we need to have them ordered to detect correctly the thermal events.

I see.

So this mostly is a preparation for patch 4, isn't it?

> >> But if we assume they are ordered and change the code
> >> based on this assumption, any platform with shuffled trip points
> >> description will be broken (if they exist).
> >>
> >> Instead of taking the risk of breaking the existing platforms, use an
> >> array of temperature ordered trip identifiers and make it available
> >> for the code needing to browse the trip points in an ordered way.
> >
> > Well, having ops->get_trip_temp() suggests that the trip temperatures
> > can be dynamic.  Is the ordering guaranteed to be preserved in that
> > case?
>
> The number of trips can not be changed. It is fixed when the thermal
> zone is created AFAICT.

The current code appears to assume that and I think that this is a
reasonable expectation.

> The get_trip_temp() is just a way to let the
> different driver declare their own trip structure which is actually
> something I'm trying to fix by moving the structure thermal_trip inside
> the thermal zone. But that is a longer and separate work.

Well, I'm not sure.

Trip point temperatures can be set via trip_point_temp_store() at
least in principle.  How is it guaranteed that this won't affect the
ordering?

> > Anyway, if they need to be sorted, why don't we just sort them
> > properly instead of adding this extra array?
>
> We can not because ATM the trip points array is private to the different
> sensors.

Well, the core could create an array or list of trip points for the
thermal zone during registration and populate it from the
driver-provided data.  Then, it could be sorted at the creation time.

However, the above question needs to be addressed first.