| Message ID | 20231118124252.14838-2-wahrenst@gmx.net |
|---|---|
| State | Superseded |
| Headers | show |
| Series | ARM: dts: bcm2711-rpi-400: Fix delete-node of led_act | expand |
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?
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? >
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?
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 > >
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
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
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
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 --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); }
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