linux-kernel - Re: [PATCH 00/15] thermal OF rework

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] [day] [month] [year] [list]

Date:   Tue, 17 May 2022 18:02:24 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Daniel Lezcano <daniel.lezcano@...exp.org>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Kevin Hilman <khilman@...libre.com>,
        Alexandre Bailon <abailon@...libre.com>,
        Linux PM <linux-pm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
Subject: Re: [PATCH 00/15] thermal OF rework

On Wed, Apr 27, 2022 at 12:15 AM Daniel Lezcano
<daniel.lezcano@...exp.org> wrote:
>
> The thermal framework initialization with the device tree appears to
> be complicated and hard to make it to evolve.
>
> It contains duplication of almost the same thermal generic structures
> and has an assymetric initialization making hard any kind of serious
> changes for more complex features. One of them is the multiple sensors
> support per thermal zone.
>
> In order to set the scene for the aforementioned feature with generic
> code, we need to cleanup and rework the device tree initialization.
>
> However this rework is not obvious because of the multiple components
> entering in the composition of a thermal zone and being initialized at
> different moments. For instance, a cooling device can be initialized
> before a sensor, so the thermal zones must exist before the cooling
> device as well as the sensor. This asynchonous initialization forces
> the thermal zone to be created with fake ops because they are
> mandotory and build a list of cooling devices which is used to lookup
> afterwards when the cooling device driver is registering itself.
>
> Actually, the correct behavior IMHO, would be having a sensor
> registration resulting in the thermal zone creation. If the cooling
> device is registered before, it won't find the thermal zone and should
> return -EPROBE_DEFER.
>
> As there could be a large number of changes, this first series provide
> some steps forward for a simpler device tree initialization.
>
> The first patch could appear scary as it touches a big number of files
> but it is actually just renaming a structure name
>
> Daniel Lezcano (15):
>   thermal/core: Rename thermal_zone_device to thermal_zone
>   thermal/core: Change thermal_zone_ops to thermal_sensor_ops
>   thermal/core: Add a thermal sensor structure in the thermal zone
>   thermal/core: Remove duplicate information when an error occurs
>   thermal/of: Replace device node match with device node search
>   thermal/of: Remove the device node pointer for thermal_trip
>   thermal/of: Move thermal_trip structure to thermal.h
>   thermal/core: Remove unneeded EXPORT_SYMBOLS
>   thermal/core: Move thermal_set_delay_jiffies to static
>   thermal/core: Rename trips to ntrips
>   thermal/core: Add thermal_trip in thermal_zone
>   thermal/core: Register with the trip points
>   thermal/of: Store the trips in the thermal zone
>   thermal/of: Use thermal trips stored in the thermal zone
>   thermal/of: Initialize trip points separately

Generally, the series looks reasonable to me, but I'm not convinced
about the first patch.

It looks like a decision needs to be made regarding how exactly a
"thermal zone" is going to be defined now and how it is going to be
related to thermal sensors.

My basic question is this: If trip points are associated with thermal
sensors, then what a thermal zone really is and what is it useful for?