linux-kernel - Re: [PATCH v1 2/3] gpiolib: Rename gpio_set_debounce_timeout() to gpiod_do_set

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMRc=MfsKc+r=uhDZVbd_BW=Gs1BpaidPC1tfF6TGqcq9bgP6Q@mail.gmail.com>
Date: Tue, 4 Mar 2025 13:15:02 +0100
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Mika Westerberg <mika.westerberg@...ux.intel.com>, 
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>, linux-gpio@...r.kernel.org, 
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Mika Westerberg <westeri@...nel.org>, Linus Walleij <linus.walleij@...aro.org>, 
	Kent Gibson <warthog618@...il.com>
Subject: Re: [PATCH v1 2/3] gpiolib: Rename gpio_set_debounce_timeout() to gpiod_do_set_debounce()

On Tue, Mar 4, 2025 at 1:00 PM Andy Shevchenko
<andriy.shevchenko@...ux.intel.com> wrote:
>
> On Tue, Mar 04, 2025 at 01:31:35PM +0200, Mika Westerberg wrote:
> > On Tue, Mar 04, 2025 at 01:16:54PM +0200, Andy Shevchenko wrote:
> > > On Tue, Mar 04, 2025 at 01:11:57PM +0200, Mika Westerberg wrote:
> > > > On Tue, Mar 04, 2025 at 12:59:25PM +0200, Andy Shevchenko wrote:
> > > > > On Tue, Mar 04, 2025 at 11:18:04AM +0200, Mika Westerberg wrote:
> > > > > > On Mon, Mar 03, 2025 at 06:00:33PM +0200, Andy Shevchenko wrote:
> > > > > > > In order to reduce the 'gpio' namespace when operate over GPIO descriptor
> > > > > > > rename gpio_set_debounce_timeout() to gpiod_do_set_debounce().
> > > > > >
> > > > > > To me anything that has '_do_' in their name sounds like an internal static
> > > > > > function that gets wrapped by the actual API function(s).
> > > > > >
> > > > > > For instance it could be
> > > > > >
> > > > > >   int gpio_set_debounce_timeout()
> > > > > >   {
> > > > > >       ...
> > > > > >       gpiod_do_set_debounce()
> > > > > >       ...
> > > > > >
> > > > > > However, gpiod_set_debounce_timeout() or gpiod_set_debounce() sounds good
> > > > > > to me.
> > > > >
> > > > > Then please propose the second name for gpiod_set_config_XXX to follow
> > > > > the same pattern. The series unifies naming and reduces the current
> > > > > inconsistency.
> > >
> > > > gpiod_set_config()?
> > >
> > > The problem is that
> > >
> > > gpiod_set_debounce() and gpiod_set_config() are _existing_ public APIs.
> > > That's why I considered "_do_" fitting the purpose.
> >
> > I see.
> >
> > Hmm, we have:
> >
> > int gpiod_set_debounce(struct gpio_desc *desc, unsigned int debounce)
> > {
> >         unsigned long config;
> >
> >         config = pinconf_to_config_packed(PIN_CONFIG_INPUT_DEBOUNCE, debounce);
> >         return gpiod_set_config(desc, config);
> > }
> >
> > and
> >
> > int gpio_set_debounce_timeout(struct gpio_desc *desc, unsigned int debounce)
> > {
> >       int ret;
> >
> >       ret = gpio_set_config_with_argument_optional(desc,
> >                                                    PIN_CONFIG_INPUT_DEBOUNCE,
> >                                                    debounce);
> >       if (!ret)
> >               gpiod_line_state_notify(desc, GPIO_V2_LINE_CHANGED_CONFIG);
> >
> >       return ret;
> > }
> >
> > I wonder if there is an opportunity to consolidate? ;-)
>
> Send a patch! I would be glad to see less functions and internal APIs in
> GPIOLIB.
>

I'm definitely in favor of consolidation instead of renaming to
gpiod_go_set_debounce(). If anything a better name would be:
gpiod_set_debounce_nocheck() to indicate the actual functionality.

How about first extending gpio_set_config_with_argument() to take a
boolean "optional" argument and removing
gpio_set_config_with_argument_optional() altogether? Both are internal
to drivers/gpio/ so it would have no effect on consumers.

Bart