Re: [PATCH v2] gpiolib: Disallow identical line names in the same chip

[Bartosz Golaszewski <bgolaszewski@baylibre.com>]

On Wed, Jan 6, 2021 at 2:34 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Wed, Jan 6, 2021 at 12:09 PM Bartosz Golaszewski
> <bgolaszewski@baylibre.com> wrote:
> > On Wed, Jan 6, 2021 at 12:24 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> > > On Tue, Jan 5, 2021 at 6:28 PM Andy Shevchenko
> > > <andy.shevchenko@gmail.com> wrote:
> > > > On Tue, Jan 5, 2021 at 10:31 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> > > > > We need to make this namespace hierarchical: at least do not
> > > > > allow two lines on the same chip to have the same name, this
> > > > > is just too much flexibility. If we name a line on a chip,
> > > > > name it uniquely on that chip.
> > > > >
> > > > > This does not affect device tree and other gpiochips that
> > > > > get named from device properties: the uniqueness
> > > > > per-chip however affect all hotplugged devices such as
> > > > > GPIO expanders on USB.
> > > >
> > > > ...
> > > >
> > > > > [Dropped warning for globally unique]
> > > >
> > > > > + * - Allow names to not be globally unique but warn about it.
> > > >
> > > > Is the second part of this sentence still ture?
> > > > Maybe I missed a warning we are talking about here?
> > >
> > > Oops old text, Bartosz if this looks OK otherwise can you fix
> > > this when applying? (Just delete that line.)
>
> > I can do it alright. But in the context of user-space I think this
> > doesn't really change anything. DT users still can use non-unique
> > names and libgpiod still has to account for that if the API is to be
> > considered correct. Is this change really useful?
>
> IMHO it is useful and the earliest we do the better.
>

I'm wondering if user-space should make this assumption too then. That
a non-unique name is either an error or signifies some special value
(N/A).

> > How does it affect
> > ACPI users that already define non-unique names?
>
> I suppose that in ACPI we don't have many users that do it on their
> own (for IoT Intel platforms GPIO expanders have unique names).
> Also see above. I prefer to have a bug report with a clear source of
> the issue (like a table that the user can't / won't change which
> predates the date of kernel release with a patch.
>
> +cc: to the user who lately was active in the area.
>
> Flavio, perhaps one more rule to the gpio-line-names property has to
> be added into documentation (Bart, same to DT docs?):
>  - names inside one chip must be unique
>

Once we have a proper, core yaml binding for all GPIO devices, we'll
be able to even enforce it if we agree on a set of exceptions.

Bart