[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJZ5v0hMVDePyu53hLyoxOZuScuUD_oQGE+NrnnhHqQwi-8o3g@mail.gmail.com>
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?
Powered by blists - more mailing lists