Re: [PATCH v5 2/3] usb: serial: xr_serial: Add gpiochip support

[Linus Walleij]

On Wed, Dec 9, 2020 at 4:24 PM Johan Hovold <johan@xxxxxxxxxx> wrote:
> On Tue, Dec 08, 2020 at 01:41:52PM +0100, Linus Walleij wrote:

> > depends on !GPIO_SYSFS
> >
> > so it can't even be compiled in if someone is using the sysfs.
> >
> > That should solve the situation where people are (ab)using
> > the sysfs and getting name collisions as a result.
>
> Would it possible to set a flag to suppress just the sysfs entry
> renaming instead?

Hm you mean that when a GPIO is "exported" in sysfs
it should not get a symbolic name from the names but instead
just the number?

I bet someone has written their scripts to take advantage of
the symbolic names so I suspect the task becomes bigger
like suppress the sysfs entry renaming if and only if there is
a namespace collision.

But I think we can do that, doesn't seem too hard?

I just hacked up this:
https://lore.kernel.org/linux-gpio/20201209161821.92931-1-linus.walleij@xxxxxxxxxx/T/#u

> Despite its flaws the sysfs interface is still very convenient and I'd
> prefer not to disable it just because of the line names.

Would these conveniences be identical to those listed
in my recent TODO entry?
https://lore.kernel.org/linux-gpio/20201204083533.65830-1-linus.walleij@xxxxxxxxxx/

There are several other issues with the sysfs, so making it conflict
with other drivers is almost  plus in the direction of discouragement
from the GPIO submaintainer point of view, but I do see that
people like it for the reasons in the TODO. :/

I am strongly encouraging any developer with a few spare cycles
on their hands to go and implement the debugfs facility because
we can make it so much better than the sysfs, easier and
more convenient for testing etc.

> > Then it should be fine for any driver to provide a names array
> > provided all the names are unique on that gpiochip.
>
> So it sounds like there's nothing preventing per-chip-unique names in
> the rest of gpiolib and the new chardev interface then? Are the
> user-space libraries able to cope with it, etc?

Yes the documentation refers to libgpiod a very well maintained
library:
https://www.kernel.org/doc/html/latest/driver-api/gpio/using-gpio.html
https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/

Then there are the the example tools included with the kernel
that provide a second implementation for the same interfaces
using just the C standard library:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/gpio

I usually use the tools myself.

Yours,
Linus Walleij