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: <fb14ae2a-9702-1041-ae84-34d37835e839@linaro.org>
Date:   Mon, 8 Aug 2022 23:17:38 +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 2/4] thermal/of: Return -ENODEV instead of -EINVAL if
 registration fails
Content-Language: en-US
To:     Michael Walle <michael@walle.cc>,
        Guenter Roeck <linux@roeck-us.net>
Cc:     rafael@kernel.org, dan.carpenter@oracle.com,
        linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
        Amit Kucheria <amitk@kernel.org>,
        Zhang Rui <rui.zhang@intel.com>
References: <20220808180915.446053-1-daniel.lezcano@linaro.org>
 <20220808180915.446053-2-daniel.lezcano@linaro.org>
 <f8008f05-4e4d-e21f-2e40-e234930ee86e@roeck-us.net>
 <d676c6533e11ac357a8aaca4ba216b6d@walle.cc>
From:   Daniel Lezcano <daniel.lezcano@linaro.org>
In-Reply-To: <d676c6533e11ac357a8aaca4ba216b6d@walle.cc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 08/08/2022 21:05, Michael Walle wrote:
> Am 2022-08-08 20:35, schrieb Guenter Roeck:
>> On 8/8/22 11:09, Daniel Lezcano wrote:
>>> The previous version of the OF code was returning -ENODEV if no
>>> thermal zones description was found or if the lookup of the sensor in
>>> the thermal zones was not found.
>>>
>>> The backend drivers are expecting this return value as an information
>>> about skipping the sensor initialization and considered as normal.
>>>
>>> Fix the return value by replacing -EINVAL by -ENODEV
>>>
>>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>>> ---
>>>   drivers/thermal/thermal_of.c | 4 ++--
>>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/thermal/thermal_of.c b/drivers/thermal/thermal_of.c
>>> index 368eb58e97cf..4210c18ef7b2 100644
>>> --- a/drivers/thermal/thermal_of.c
>>> +++ b/drivers/thermal/thermal_of.c
>>> @@ -329,7 +329,7 @@ static struct device_node 
>>> *of_thermal_zone_find(struct device_node *sensor, int
>>>       np = of_find_node_by_name(NULL, "thermal-zones");
>>>       if (!np) {
>>>           pr_err("Unable to find thermal zones description\n");
>>
>> I really don't like that error message: People will see it (and complain)
>> whenever a sensor registers and there is no thermal zone, even though 
>> that
>> is perfectly normal (see description above).
> 
> I can second that, and there actually two error messages:
> 
> [    6.156983] thermal_sys: Unable to find thermal zones description
> [    6.163125] thermal_sys: Failed to find thermal zone for hwmon id=0

Yeah, I can check:

np = of_thermal_zone_find(sensor, id);

And print the error if PTR_ERR(np) != ENODEV, otherwise silently return.


> On the sl28 board with the qoriq_thermal driver:
> [    1.917940] thermal_sys: Failed to find thermal zone for tmu id=2
> [    1.929231] thermal_sys: Failed to find thermal zone for tmu id=3
> [    1.940519] thermal_sys: Failed to find thermal zone for tmu id=4
> [    1.951814] thermal_sys: Failed to find thermal zone for tmu id=5
> [    1.963109] thermal_sys: Failed to find thermal zone for tmu id=6
> [    1.974399] thermal_sys: Failed to find thermal zone for tmu id=7
> [    1.985690] thermal_sys: Failed to find thermal zone for tmu id=8
> [    1.996980] thermal_sys: Failed to find thermal zone for tmu id=9
> [    2.008274] thermal_sys: Failed to find thermal zone for tmu id=10
> [    2.019656] thermal_sys: Failed to find thermal zone for tmu id=11
> [    2.031037] thermal_sys: Failed to find thermal zone for tmu id=12
> [    2.048942] thermal_sys: Failed to find thermal zone for tmu id=13
> [    2.060320] thermal_sys: Failed to find thermal zone for tmu id=14
> [    2.071700] thermal_sys: Failed to find thermal zone for tmu id=15
> 
> Btw. the driver seems to always register 16 sensors regardless how
> many the actual hardware has (or rather: are described in the DT).

Yes, it may be nicer to rely on the compatible string to figure out the 
sensors of the platform and call with full knowledge the registering 
function. But anyway ...


-- 
<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