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