On Tue, Dec 08, 2020 at 01:41:52PM +0100, Linus Walleij wrote: > On Tue, Dec 8, 2020 at 10:57 AM Johan Hovold <johan@xxxxxxxxxx> wrote: > > Well we started discussing this back when we only had the sysfs > > interface which suffered from the same problem. I thought the chardev > > interface was supposed to get rid of the assumption of a flat name > > space? Perhaps in v3 of the ABI. ;P > > It's "mostly true" that the line names are unique per-chip actually, > because people don't like the nasty warning message. I wonder > if anything would really break if I go in and make a patch to > enforce it, since all drivers passing ->names in the gpiochip > are in the kernel we can check them all. > > If the names are unique-per-chip, we can add a restriction like this > with the requirement: > > 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? Despite its flaws the sysfs interface is still very convenient and I'd prefer not to disable it just because of the line names. > 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? > I doubt it would break anything, but let's see what Geert says. > He has some special usecases in the gpio-aggregator driver > which will incidentally look for just linenames when > aggregating gpios, but I feel it is a bit thick for it to work > with multiple hot-pluggable GPIO chips as well, I don't think > that is its usecase. (We all want to be perfect but...) Ok. > > But what about any other non-pluggable > > IC, which provides a few named GPIO lines and of which there could be > > more than one in a system? > > I think if there are such, and the lines are unique per-chip > we should make the drivers depend on !GPIO_SYSFS. Or just suppress the sysfs-entry renaming if that's the only thing that's blocking this. Johan
