[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZVQg9hTQwGtNwIhv@surfacebook.localdomain>
Date: Wed, 15 Nov 2023 03:37:58 +0200
From: andy.shevchenko@...il.com
To: Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Bartosz Golaszewski <bartosz.golaszewski@...aro.org>,
Linus Walleij <linus.walleij@...aro.org>,
linux-gpio@...r.kernel.org, linux-acpi@...r.kernel.org,
linux-kernel@...r.kernel.org,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
Bartosz Golaszewski <brgl@...ev.pl>,
Hans de Goede <hdegoede@...hat.com>,
Ferry Toth <ftoth@...londelft.nl>
Subject: Re: [PATCH v1 2/3] gpiolib: Fix debug messaging in
gpiod_find_and_request()
Tue, Nov 14, 2023 at 09:18:24PM +0000, Dmitry Torokhov kirjoitti:
> On Tue, Nov 14, 2023 at 05:29:59PM +0200, Andy Shevchenko wrote:
> > On Thu, Oct 19, 2023 at 12:21:12PM -0700, Dmitry Torokhov wrote:
> > > On Thu, Oct 19, 2023 at 08:34:56PM +0300, Andy Shevchenko wrote:
> > > > When consolidating GPIO lookups in ACPI code, the debug messaging
> > > > had been broken and hence lost a bit of sense. Restore debug
> > > > messaging in gpiod_find_and_request() when configuring the GPIO
> > > > line via gpiod_configure_flags().
> > >
> > > Could you give an example of the before/after messages to show exavtly
> > > what is being improved?
> >
> > Before your patch:
> >
> > [ 5.266823] gpio-96 (ACPI:OpRegion): no flags found for ACPI:OpRegion
> > [ 14.182994] gpio-40 (?): no flags found for gpios
> >
> > After your patch:
> >
> > [ 5.085048] gpio-96 (ACPI:OpRegion): no flags found for ACPI:OpRegion
> > [ 13.401402] gpio-40 (?): no flags found for (null)
> >
> > After this patch:
> >
> > [ 3.871185] gpio-96 (ACPI:OpRegion): no flags found for ACPI:OpRegion
> > [ 12.491998] gpio-40 (?): no flags found for gpios
> >
> > ...
> >
> > Looking at this it's definitely a fix.
>
> If this ("(null)" vs static "gpios" string) is important, can we reduce
> the patch to:
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 76e0c38026c3..b868c016a9be 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -4151,7 +4151,7 @@ int gpiod_configure_flags(struct gpio_desc *desc, const char *con_id,
>
> /* No particular flag request, return here... */
> if (!(dflags & GPIOD_FLAGS_BIT_DIR_SET)) {
> - gpiod_dbg(desc, "no flags found for %s\n", con_id);
> + gpiod_dbg(desc, "no flags found for %s\n", con_id ?: "gpios");
> return 0;
> }
>
>
> instead of plumbing the names through?
Definitely no, because how can you guess that this is "gpios" and not "gpio"?
> Although this (and the original fix patch) are losing information, in
> the sense that "(null)" explicitly communicates that caller used
> default/NULL conn_id, and not something like "gpios-gpios".
This is not true, there was no such information before your patch and NULL
pointer printing is simply a bad style programming. We already had the cases
when users were scary by "NULL device *" and other similar stuff when it's
practically no problems in the flow. This has to be fixed anyway.
And what's the practical meaning of gpios-gpios / gpio-gpios / gpios-gpio /
gpio-gpio? I believe they are so weird that thinking about them would be lowest
priority over the issues with the messaging there.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists