Am 22.11.23 um 11:52 schrieb Bartosz Golaszewski:
On Mon, Nov 20, 2023 at 1:36 PM Andy Shevchenko
<andriy.shevchenko@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
