diff mbox series

[V2,1/2] leds: gpio: Add kernel log if devm_fwnode_gpiod_get fails

Message ID 20231118124252.14838-2-wahrenst@gmx.net (mailing list archive)
State New, archived
Headers show
Series ARM: dts: bcm2711-rpi-400: Fix delete-node of led_act | expand

Commit Message

Stefan Wahren Nov. 18, 2023, 12:42 p.m. UTC
In case leds-gpio fails to get the GPIO from the DT (e.g. the GPIO is
already requested) the driver doesn't provide any helpful error log:

    leds-gpio: probe of leds failed with error -16

So add a new error log in case devm_fwnode_gpiod_get() fails.

Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
---
 drivers/leds/leds-gpio.c | 2 ++
 1 file changed, 2 insertions(+)

--
2.34.1

Comments

Andy Shevchenko Nov. 20, 2023, 11:47 a.m. UTC | #1
On Sat, Nov 18, 2023 at 01:42:51PM +0100, Stefan Wahren wrote:
> In case leds-gpio fails to get the GPIO from the DT (e.g. the GPIO is
> already requested) the driver doesn't provide any helpful error log:
> 
>     leds-gpio: probe of leds failed with error -16
> 
> So add a new error log in case devm_fwnode_gpiod_get() fails.

...

>  		led.gpiod = devm_fwnode_gpiod_get(dev, child, NULL, GPIOD_ASIS,
>  						  NULL);
>  		if (IS_ERR(led.gpiod)) {
> +			dev_err_probe(dev, PTR_ERR(led.gpiod), "Failed to get gpio '%pfw'\n",
> +				      child);
>  			fwnode_handle_put(child);
>  			return ERR_CAST(led.gpiod);
>  		}

Thinking more about it. GPIO library already issues bunch of messages.

	"using DT ... for ... GPIO lookup"
	"using lookup tables for GPIO lookup"
	"No GPIO consumer ... found"

Isn't it enough?
Stefan Wahren Nov. 20, 2023, 12:02 p.m. UTC | #2
Hi Andy,

[add Linus and Bartosz]

Am 20.11.23 um 12:47 schrieb Andy Shevchenko:
> On Sat, Nov 18, 2023 at 01:42:51PM +0100, Stefan Wahren wrote:
>> In case leds-gpio fails to get the GPIO from the DT (e.g. the GPIO is
>> already requested) the driver doesn't provide any helpful error log:
>>
>>      leds-gpio: probe of leds failed with error -16
>>
>> So add a new error log in case devm_fwnode_gpiod_get() fails.
> ...
>
>>   		led.gpiod = devm_fwnode_gpiod_get(dev, child, NULL, GPIOD_ASIS,
>>   						  NULL);
>>   		if (IS_ERR(led.gpiod)) {
>> +			dev_err_probe(dev, PTR_ERR(led.gpiod), "Failed to get gpio '%pfw'\n",
>> +				      child);
>>   			fwnode_handle_put(child);
>>   			return ERR_CAST(led.gpiod);
>>   		}
> Thinking more about it. GPIO library already issues bunch of messages.
>
> 	"using DT ... for ... GPIO lookup"
> 	"using lookup tables for GPIO lookup"
> 	"No GPIO consumer ... found"
are these errors or debug messages?

I cannot remember that i saw any of them on info level in my case of an
already allocated pin (see patch 2).

I'm open to place the log within gpiolib, if this a better place.

Best regards
>
> Isn't it enough?
>
Andy Shevchenko Nov. 20, 2023, 12:36 p.m. UTC | #3
On Mon, Nov 20, 2023 at 01:02:55PM +0100, Stefan Wahren wrote:
> Am 20.11.23 um 12:47 schrieb Andy Shevchenko:
> > On Sat, Nov 18, 2023 at 01:42:51PM +0100, Stefan Wahren wrote:
> > > In case leds-gpio fails to get the GPIO from the DT (e.g. the GPIO is
> > > already requested) the driver doesn't provide any helpful error log:
> > > 
> > >      leds-gpio: probe of leds failed with error -16
> > > 
> > > So add a new error log in case devm_fwnode_gpiod_get() fails.

...

> > >   		led.gpiod = devm_fwnode_gpiod_get(dev, child, NULL, GPIOD_ASIS,
> > >   						  NULL);
> > >   		if (IS_ERR(led.gpiod)) {
> > > +			dev_err_probe(dev, PTR_ERR(led.gpiod), "Failed to get gpio '%pfw'\n",
> > > +				      child);
> > >   			fwnode_handle_put(child);
> > >   			return ERR_CAST(led.gpiod);
> > >   		}
> > Thinking more about it. GPIO library already issues bunch of messages.
> > 
> > 	"using DT ... for ... GPIO lookup"
> > 	"using lookup tables for GPIO lookup"
> > 	"No GPIO consumer ... found"
> are these errors or debug messages?

Indeed they are on debug level.

> I cannot remember that i saw any of them on info level in my case of an
> already allocated pin (see patch 2).
> 
> I'm open to place the log within gpiolib, if this a better place.

I'm not sure, let's hear GPIO maintainers for that.

> > Isn't it enough?
Bartosz Golaszewski Nov. 22, 2023, 10:52 a.m. UTC | #4
On Mon, Nov 20, 2023 at 1:36 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, Nov 20, 2023 at 01:02:55PM +0100, Stefan Wahren wrote:
> > Am 20.11.23 um 12:47 schrieb Andy Shevchenko:
> > > On Sat, Nov 18, 2023 at 01:42:51PM +0100, Stefan Wahren wrote:
> > > > In case leds-gpio fails to get the GPIO from the DT (e.g. the GPIO is
> > > > already requested) the driver doesn't provide any helpful error log:
> > > >
> > > >      leds-gpio: probe of leds failed with error -16
> > > >
> > > > So add a new error log in case devm_fwnode_gpiod_get() fails.
>
> ...
>
> > > >                   led.gpiod = devm_fwnode_gpiod_get(dev, child, NULL, GPIOD_ASIS,
> > > >                                                     NULL);
> > > >                   if (IS_ERR(led.gpiod)) {
> > > > +                 dev_err_probe(dev, PTR_ERR(led.gpiod), "Failed to get gpio '%pfw'\n",
> > > > +                               child);
> > > >                           fwnode_handle_put(child);
> > > >                           return ERR_CAST(led.gpiod);
> > > >                   }
> > > Thinking more about it. GPIO library already issues bunch of messages.
> > >
> > >     "using DT ... for ... GPIO lookup"
> > >     "using lookup tables for GPIO lookup"
> > >     "No GPIO consumer ... found"
> > are these errors or debug messages?
>
> Indeed they are on debug level.
>
> > I cannot remember that i saw any of them on info level in my case of an
> > already allocated pin (see patch 2).
> >
> > I'm open to place the log within gpiolib, if this a better place.
>
> I'm not sure, let's hear GPIO maintainers for that.
>

Hard to tell which method is preferred among all the subsystems.
Personally I'm more inclined towards letting drivers decide whether to
emit an error message and only emit our own when an error cannot be
propagated down the stack.

Linus: Any thoughts?

Bart

> > > Isn't it enough?
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
Stefan Wahren Nov. 28, 2023, 5:15 p.m. UTC | #5
Am 22.11.23 um 11:52 schrieb Bartosz Golaszewski:
> On Mon, Nov 20, 2023 at 1:36 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
>> On Mon, Nov 20, 2023 at 01:02:55PM +0100, Stefan Wahren wrote:
>>> Am 20.11.23 um 12:47 schrieb Andy Shevchenko:
>>>> On Sat, Nov 18, 2023 at 01:42:51PM +0100, Stefan Wahren wrote:
>>>>> In case leds-gpio fails to get the GPIO from the DT (e.g. the GPIO is
>>>>> already requested) the driver doesn't provide any helpful error log:
>>>>>
>>>>>       leds-gpio: probe of leds failed with error -16
>>>>>
>>>>> So add a new error log in case devm_fwnode_gpiod_get() fails.
>> ...
>>
>>>>>                    led.gpiod = devm_fwnode_gpiod_get(dev, child, NULL, GPIOD_ASIS,
>>>>>                                                      NULL);
>>>>>                    if (IS_ERR(led.gpiod)) {
>>>>> +                 dev_err_probe(dev, PTR_ERR(led.gpiod), "Failed to get gpio '%pfw'\n",
>>>>> +                               child);
>>>>>                            fwnode_handle_put(child);
>>>>>                            return ERR_CAST(led.gpiod);
>>>>>                    }
>>>> Thinking more about it. GPIO library already issues bunch of messages.
>>>>
>>>>      "using DT ... for ... GPIO lookup"
>>>>      "using lookup tables for GPIO lookup"
>>>>      "No GPIO consumer ... found"
>>> are these errors or debug messages?
>> Indeed they are on debug level.
>>
>>> I cannot remember that i saw any of them on info level in my case of an
>>> already allocated pin (see patch 2).
>>>
>>> I'm open to place the log within gpiolib, if this a better place.
>> I'm not sure, let's hear GPIO maintainers for that.
>>
> Hard to tell which method is preferred among all the subsystems.
> Personally I'm more inclined towards letting drivers decide whether to
> emit an error message and only emit our own when an error cannot be
> propagated down the stack.
>
> Linus: Any thoughts?
gentle ping ...
>
> Bart
>
>>>> Isn't it enough?
>> --
>> With Best Regards,
>> Andy Shevchenko
>>
>>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Linus Walleij Nov. 29, 2023, 2:03 p.m. UTC | #6
On Wed, Nov 22, 2023 at 11:53 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:

> > > I cannot remember that i saw any of them on info level in my case of an
> > > already allocated pin (see patch 2).
> > >
> > > I'm open to place the log within gpiolib, if this a better place.
> >
> > I'm not sure, let's hear GPIO maintainers for that.
>
> Hard to tell which method is preferred among all the subsystems.
> Personally I'm more inclined towards letting drivers decide whether to
> emit an error message and only emit our own when an error cannot be
> propagated down the stack.
>
> Linus: Any thoughts?

I never managed to get it right so I can't give any good advice.

Usually I tend to think better one more error message than one too little.

Then again I'm a dmesg maximalist who just want it to scroll on forever
also with positive messages...

Yours,
Linus Walleij
Stefan Wahren Nov. 29, 2023, 3:07 p.m. UTC | #7
Am 29.11.23 um 15:03 schrieb Linus Walleij:
> On Wed, Nov 22, 2023 at 11:53 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
>>>> I cannot remember that i saw any of them on info level in my case of an
>>>> already allocated pin (see patch 2).
>>>>
>>>> I'm open to place the log within gpiolib, if this a better place.
>>> I'm not sure, let's hear GPIO maintainers for that.
>> Hard to tell which method is preferred among all the subsystems.
>> Personally I'm more inclined towards letting drivers decide whether to
>> emit an error message and only emit our own when an error cannot be
>> propagated down the stack.
>>
>> Linus: Any thoughts?
> I never managed to get it right so I can't give any good advice.
>
> Usually I tend to think better one more error message than one too little.
>
> Then again I'm a dmesg maximalist who just want it to scroll on forever
> also with positive messages...
Okay, based on the feedback this sounds like nobody is against this patch?
>
> Yours,
> Linus Walleij
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Lee Jones Dec. 1, 2023, 11:23 a.m. UTC | #8
On Sat, 18 Nov 2023, Stefan Wahren wrote:

> In case leds-gpio fails to get the GPIO from the DT (e.g. the GPIO is
> already requested) the driver doesn't provide any helpful error log:
> 
>     leds-gpio: probe of leds failed with error -16
> 
> So add a new error log in case devm_fwnode_gpiod_get() fails.
> 
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
> ---
>  drivers/leds/leds-gpio.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
> index 710c319ad312..0159cedffa9e 100644
> --- a/drivers/leds/leds-gpio.c
> +++ b/drivers/leds/leds-gpio.c
> @@ -172,6 +172,8 @@ static struct gpio_leds_priv *gpio_leds_create(struct device *dev)
>  		led.gpiod = devm_fwnode_gpiod_get(dev, child, NULL, GPIOD_ASIS,
>  						  NULL);
>  		if (IS_ERR(led.gpiod)) {
> +			dev_err_probe(dev, PTR_ERR(led.gpiod), "Failed to get gpio '%pfw'\n",

Nit: GPIO

> +				      child);
>  			fwnode_handle_put(child);
>  			return ERR_CAST(led.gpiod);
>  		}
> --
> 2.34.1
>
diff mbox series

Patch

diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
index 710c319ad312..0159cedffa9e 100644
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -172,6 +172,8 @@  static struct gpio_leds_priv *gpio_leds_create(struct device *dev)
 		led.gpiod = devm_fwnode_gpiod_get(dev, child, NULL, GPIOD_ASIS,
 						  NULL);
 		if (IS_ERR(led.gpiod)) {
+			dev_err_probe(dev, PTR_ERR(led.gpiod), "Failed to get gpio '%pfw'\n",
+				      child);
 			fwnode_handle_put(child);
 			return ERR_CAST(led.gpiod);
 		}