lkml.org 
[lkml]   [2022]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 00/15] thermal OF rework
    On Wed, Apr 27, 2022 at 12:15 AM Daniel Lezcano
    <daniel.lezcano@linexp.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?

    \
     
     \ /
      Last update: 2022-05-17 18:03    [W:3.891 / U:0.080 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site