[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <daae2f05-66ea-4f21-a47d-6e384bd35dee@linaro.org>
Date: Thu, 9 Nov 2023 17:18:24 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Guenter Roeck <linux@...ck-us.net>,
Javier Carrasco <javier.carrasco.cruz@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
Jean Delvare <jdelvare@...e.com>,
Jonathan Corbet <corbet@....net>,
Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>
Cc: Rob Herring <robh@...nel.org>, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-hwmon@...r.kernel.org,
linux-doc@...r.kernel.org
Subject: Re: [PATCH v2 3/4] hwmon: Add support for Amphenol ChipCap 2
On 09/11/2023 15:55, Guenter Roeck wrote:
>>> + if (IS_ERR(data->hwmon)) {
>>> + ret = PTR_ERR(data->hwmon);
>>> + goto cleanup;
>>> + }
>>> +
>>> + return 0;
>>> +
>>> +cleanup:
>>> + if (cc2_disable(data))
>>> + dev_dbg(dev, "Failed to disable device");
>>> +
>>> + return dev_err_probe(dev, ret,
>>> + "Unable to register hwmon device\n");
>>
>> Drop or move to each error path.
>>
> This actually follows Documentation/process/coding-style.rst, chapter 7
> (Centralized exiting of functions).
The point is that centralized message of error is useless. Probe failure
is already handled by core, thus another message doing the same is
redundant. What is needed to explain the true reason of failure, thus
the error message should be next to each type of failure. Missing
regulator? Say it. Missing clock? Say something else.
Best regards,
Krzysztof
Powered by blists - more mailing lists