| Message ID | 20240305101042.10953-2-u.kleine-koenig@pengutronix.de (mailing list archive) |
|---|---|
| State | Mainlined |
| Commit | 963465a33141d0d52338e77f80fe543d2c9dc053 |
| Headers | show |
| Series | Input: gpio_keys_polled - Suppress deferred probe error for gpio | expand |
On Tue, Mar 5, 2024 at 11:10 AM Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote: > On a PC Engines APU our admins are faced with: > > $ dmesg | grep -c "gpio-keys-polled gpio-keys-polled: unable to claim gpio 0, err=-517" > 261 > > Such a message always appears when e.g. a new USB device is plugged in. > > Suppress this message which considerably clutters the kernel log for > EPROBE_DEFER (i.e. -517). > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Fair enough, Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Yours, Linus Walleij
On Tue, Mar 5, 2024 at 12:10 PM Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote: ... > there are a few other exit paths that could use dev_err_probe(), but IIRC > Dmitry isn't a fan of using dev_err_probe() where the return value cannot be > EPROBE_DEFER, so I'm only changing this one error path. It's not true anymore. He is fine with that API, and please use it.
On Tue, Mar 05, 2024 at 07:01:02PM +0200, Andy Shevchenko wrote: > On Tue, Mar 5, 2024 at 12:10 PM Uwe Kleine-König > <u.kleine-koenig@pengutronix.de> wrote: > > ... > > > there are a few other exit paths that could use dev_err_probe(), but IIRC > > Dmitry isn't a fan of using dev_err_probe() where the return value cannot be > > EPROBE_DEFER, so I'm only changing this one error path. > > It's not true anymore. He is fine with that API, and please use it. I would not get ahead of ourselves ;) I still think we could have done this better by: 1. Having a format option for printing symbolic errors 2. Recording deferral source at supplier level But yes, I am accepting patches and new drivers using dev_err_probe(). Thanks.
On Tue, Mar 05, 2024 at 11:10:42AM +0100, Uwe Kleine-König wrote: > On a PC Engines APU our admins are faced with: > > $ dmesg | grep -c "gpio-keys-polled gpio-keys-polled: unable to claim gpio 0, err=-517" > 261 > > Such a message always appears when e.g. a new USB device is plugged in. > > Suppress this message which considerably clutters the kernel log for > EPROBE_DEFER (i.e. -517). I'll apply this, but that seems to be a misconfiguration somewhere - we expect deferred probes to succeed eventually, here it looks like it stays deferred forever and each time a new devices gets plugged in we try to resolve deferred probe again and again. Why doesn't gpio 0 become available? Thanks.
On Tue, Mar 05, 2024 at 09:15:06AM -0800, Dmitry Torokhov wrote: > On Tue, Mar 05, 2024 at 11:10:42AM +0100, Uwe Kleine-König wrote: > > On a PC Engines APU our admins are faced with: > > > > $ dmesg | grep -c "gpio-keys-polled gpio-keys-polled: unable to claim gpio 0, err=-517" > > 261 > > > > Such a message always appears when e.g. a new USB device is plugged in. > > > > Suppress this message which considerably clutters the kernel log for > > EPROBE_DEFER (i.e. -517). > > I'll apply this, but that seems to be a misconfiguration somewhere - we > expect deferred probes to succeed eventually, here it looks like it > stays deferred forever and each time a new devices gets plugged in we > try to resolve deferred probe again and again. > > Why doesn't gpio 0 become available? This is an x86 machine and I don't even know why the device actually exists. Also I have no idea what gpio 0 should be, there seems to be a gpio controller[1], but its GPIO numbers start at 512. I found a bug report about this this issue: https://github.com/pcengines/apu2-documentation/issues/204 Anyhow, I think my patch is fine. I forwarded the bug report to my admin who might or might not dig deeper. Best regards and thanks, Uwe [1] /sys/devices/pci0000:00/AMD0030:00/gpio/gpiochip512
diff --git a/drivers/input/keyboard/gpio_keys_polled.c b/drivers/input/keyboard/gpio_keys_polled.c index ba00ecfbd343..b41fd1240f43 100644 --- a/drivers/input/keyboard/gpio_keys_polled.c +++ b/drivers/input/keyboard/gpio_keys_polled.c @@ -315,12 +315,10 @@ static int gpio_keys_polled_probe(struct platform_device *pdev) error = devm_gpio_request_one(dev, button->gpio, flags, button->desc ? : DRV_NAME); - if (error) { - dev_err(dev, - "unable to claim gpio %u, err=%d\n", - button->gpio, error); - return error; - } + if (error) + return dev_err_probe(dev, error, + "unable to claim gpio %u\n", + button->gpio); bdata->gpiod = gpio_to_desc(button->gpio); if (!bdata->gpiod) {
On a PC Engines APU our admins are faced with: $ dmesg | grep -c "gpio-keys-polled gpio-keys-polled: unable to claim gpio 0, err=-517" 261 Such a message always appears when e.g. a new USB device is plugged in. Suppress this message which considerably clutters the kernel log for EPROBE_DEFER (i.e. -517). Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> --- Hello, there are a few other exit paths that could use dev_err_probe(), but IIRC Dmitry isn't a fan of using dev_err_probe() where the return value cannot be EPROBE_DEFER, so I'm only changing this one error path. Best regards Uwe drivers/input/keyboard/gpio_keys_polled.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) base-commit: 11afac187274a6177a7ac82997f8691c0f469e41