Re: [PATCH] Input: gpio-keys - print button label in IRQ button error messages

[Geert Uytterhoeven <geert@linux-m68k.org>]

Hi Dmitry,

On Sat, Oct 16, 2021 at 7:34 AM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Fri, Sep 24, 2021 at 09:18:02AM +0200, Geert Uytterhoeven wrote:
> > When an error message related to IRQ buttons is printed, no clue is
> > given about the actual button that caused the failure.  Fix this by
> > including the button label, to make it more obvious which button has an
> > incomplete or incorrect hardware description.
> >
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > ---
> >  drivers/input/keyboard/gpio_keys.c | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
> > index 0f2250c6aa4978d5..fc706918d7b103cb 100644
> > --- a/drivers/input/keyboard/gpio_keys.c
> > +++ b/drivers/input/keyboard/gpio_keys.c
> > @@ -617,14 +617,16 @@ static int gpio_keys_setup_key(struct platform_device *pdev,
> >               }
> >       } else {
> >               if (!button->irq) {
> > -                     dev_err(dev, "Found button without gpio or irq\n");
> > +                     dev_err(dev, "Found button %s without gpio or irq\n",
> > +                             desc);
>
> I do not believe description is mandatory, so we may end up printing
> "gpio_keys" here. I wonder if it would not be more reliable to print the
> index of the problematic key?

The description (label) is indeed not mandatory, so without that it is
as good as before ;-)

For the index, I'm wondering if the iteration order is unambiguous,
and cannot change?

So perhaps we want to print both ("button %u (%s)")?

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds