Re: [PATCH 2/2] gpiolib: rename gpio_chip_hwgpio() for consistency

[Bartosz Golaszewski]

On Tue, Sep 5, 2023 at 12:34 PM Andy Shevchenko
<andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
>
> On Tue, Sep 05, 2023 at 10:37:32AM +0200, Bartosz Golaszewski wrote:
> > On Mon, Sep 4, 2023 at 11:27 AM Andy Shevchenko
> > <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> > > On Mon, Sep 04, 2023 at 09:34:10AM +0200, Bartosz Golaszewski wrote:
> > > > From: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx>
> > > >
> > > > All other functions that manipulate a struct gpio_desc use the gpiod_
> > > > prefix. Follow this convention and rename gpio_chip_hwgpio() to
> > > > gpiod_get_hwgpio().
> > >
> > > Same comment. Also, I don't think it's good idea as it steps on the exported
> > > API's toes. I.o.w. I won't mix those two.
> >
> > Even if I agreed with your other comment, gpio_chip_hwgpio() is a
> > terrible name and if I didn't know, I couldn't tell you what it does
> > just from looking at the name.
>
> That's can be improved, my previous comments were basically to avoid
> mixing prefixes for internal and external APIs, let's say prefix them
> similarly, but for internal with space and/or more verbose naming
>
>         gpiod_          gpio_desc_
>         gpiochip_       gpio_chip_
>         gdev_           gpio_device_
>

There's one more possibility. Have all exported symbols be prefixed
with gpiod in one way or another and the internal symbols just drop
the prefix so it would be like:

gpiod_
gpiochip_
gpio_device_

and

desc_
chip_
device_

Because for internal symbols we already know they refer to gpiolib.

Anyway, I'll drop the patches for now and let's revisit in the future
when the consensus is reached.

Bart

> (as an example).
>
> --
> With Best Regards,
> Andy Shevchenko
>
>