Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <53d33f48-1774-3a0e-a84e-a8027679ea5a@linaro.org>
Date:   Tue, 9 Aug 2022 17:37:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: [PATCH v5 00/33] New thermal OF code
Content-Language: en-US
To:     Guenter Roeck <linux@roeck-us.net>,
        Michael Walle <michael@walle.cc>
Cc:     daniel.lezcano@linexp.org, abailon@baylibre.com,
        anarsoul@gmail.com, baolin.wang7@gmail.com,
        bjorn.andersson@linaro.org, broonie@kernel.org,
        damien.lemoal@opensource.wdc.com, digetx@gmail.com,
        f.fainelli@gmail.com, glaroque@baylibre.com,
        hayashi.kunihiko@socionext.com, heiko@sntech.de, j-keerthy@ti.com,
        jonathanh@nvidia.com, khilman@baylibre.com,
        linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
        lukasz.luba@arm.com, matthias.bgg@gmail.com,
        mcoquelin.stm32@gmail.com, mhiramat@kernel.org,
        miquel.raynal@bootlin.com, niklas.soderlund@ragnatech.se,
        rafael@kernel.org, rui.zhang@intel.com, shawnguo@kernel.org,
        talel@amazon.com, thierry.reding@gmail.com, tiny.windzz@gmail.com
References: <20220804224349.1926752-1-daniel.lezcano@linexp.org>
 <20220808094216.928018-1-michael@walle.cc>
 <20220808102610.GA1969424@roeck-us.net>
 <829788a5-3da4-8638-a587-9e80e2fd3fea@linaro.org>
 <6318d099-268b-1bbe-fed8-4f4b356e90cb@roeck-us.net>
From:   Daniel Lezcano <daniel.lezcano@linaro.org>
In-Reply-To: <6318d099-268b-1bbe-fed8-4f4b356e90cb@roeck-us.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 09/08/2022 16:32, Guenter Roeck wrote:
> On 8/9/22 01:53, Daniel Lezcano wrote:
>> Hi Guenter,
>>
>> On 08/08/2022 12:26, Guenter Roeck wrote:
>>
>> [ ... ]
>>
>>>> But I guess even if that is fixed, the driver will not probe due to the
>>>> missing trip points? Are they now mandatory? Does it mean we'd need to
>>>> update our device trees? But that will then mean older devices trees
>>>> don't work anymore.
>>>
>>> It would also mean that all hwmon drivers registering a thermal zone 
>>> sensor
>>> would fail to register unless such a thermal zone actually exists. 
>>
>> Probably missing something but if the thermal zone is not described, 
>> the hwmon driver won't initialize. And except if I'm wrong, that was 
>> already the case before these changes, no?
>>
> 
> In the hwmon source (you point to it below):
> 
>          if (IS_ERR(tzd)) {
>                  if (PTR_ERR(tzd) != -ENODEV)
>                          return PTR_ERR(tzd);
>                  dev_info(dev, "temp%d_input not attached to any thermal 
> zone\n",
>                           index + 1);
>                  devm_kfree(dev, tdata);
>                  return 0;
>          }
> 
> That contradicts "if the thermal zone is not described, the hwmon driver 
> won't initialize".
> Now I must be missing something, since you mention that yourself below, 
> and your new patch
> series fixes the problem, at least AFAICS. Confused.

Sorry for not being clear. Let me try to explain it differently.

The function hwmon_thermal_add_sensor() is calling:


Without "[PATCH v5 00/33] New thermal OF code":
-----------------------------------------------

   devm_thermal_zone_of_sensor_register(dev, index, ...);

If there is no thermal zone description or the 'dev' does not belong to 
any thermal zone then -ENODEV is returned -> OK and the hwmon thermal 
zone is _not_ created


With "[PATCH v5 00/33] New thermal OF code":
--------------------------------------------

  devm_thermal_of_zone_register(dev, index, ...);

If there is no thermal zone description or the 'dev' does not belong to 
any thermal zone then *-EINVAL* is returned -> NOK, error message, and 
hwmon thermal zone is _not_ created


With "[PATCH v5 00/33] New thermal OF code" + fixes:
----------------------------------------------------

  devm_thermal_of_zone_register(dev, index, ...);

If there is no thermal zone description or the 'dev' does not belong to 
any thermal zone then *-ENODEV* is returned -> OK and the hwmon thermal 
zone is _not_ created


Quoting your initial message:

"It would also mean that all hwmon drivers registering a thermal zone 
sensor would fail to register unless such a thermal zone actually 
exists. This would make the whole concept of having the hwmon core 
register thermal zone sensors impossible [...]"

The thermal zone must be described if the OF registering function 
variant is used. Except I'm wrong that was already the case before the 
changes.

Otherwise, nothing prevents a hwmon to register itself with the core 
code, that will create the thermal zone.


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog