[PATCH] gpio: document how to order GPIO controllers

[Johan Hovold]

On Wed, Jul 06, 2016 at 02:34:39PM +0200, Linus Walleij wrote:
> On Wed, Jul 6, 2016 at 12:27 PM, Johan Hovold <johan at kernel.org> wrote:
> > On Wed, Jul 06, 2016 at 11:34:37AM +0200, Linus Walleij wrote:
> 
> >> I *THINK* the view of the device core maintainers is that udev
> >> and sysfs hierarchies should be used to uniquely identify a certain
> >> device, and that relying on device numbering is too fragile.
> >
> > I thought the whole idea (or at least a large part of) the new
> > user-space interface was to allow lookups by line names precisely in
> > order not to have to rely on gpio numbers, which may not only change
> > between boots, but also between hardware revisions, etc.
> 
> That is true for the individual pins, but not the device names.
> Devices are just names gpiochipN where N is the instance
> number. Topological info on the device can be found in sysfs.
> 
> The discussion here pertaining to the new chardev is just about
> the intuitiveness of the number N, whether it should be
> "whatever" or something predictable.
> 
> For the purpose of picking a certain named GPIO line (see below)
> knowing this number is unnecessary. To that mechanism all gpio
> chips are equal and the instance number does not matter.

My point was that with gpio line names (and possibly topological
information to resolve duplicates), the N number should not matter
anymore.

[ It was also a comment to a comment made earlier in the thread were the
use case was said to be to "control GPIO48 with /sys/class/gpio/gpio48".
And it seems we are in agreement there. ]

If one needs to look up a particular gpiochip based on some hardware
naming convention, why not associate a name with the chip instead of
trying to shoehorn the dynamic gpiochip range in there?

> > What's wrong with naming the pins in DT and use that for lookups?
> 
> That works. It relies on the developers using sane naming conventions
> though. (This problem is prevalent everywhere I guess, a human problem,
> not a technical one.) I made this patch:
> http://marc.info/?l=linux-arm-kernel&m=146672328215354&w=2
> 
> There is a standard document for these boards (96board) specifying
> the names of the GPIO lines to be "GPIO-A" thru "GPIO-L".
> 
> So a user can iterate across the gpiochips (as is done in lsgpio)
> and pick the lines with the right names.
> 
> This works fine, given you have such conventions or equal.
> 
> I.e. the person writing the DTS file naming the lines must not
> be a complete lunatic.

Again, it seems we're on the same page here.

> I can think of scenarios where bad use can make things problematic:
> i.e. name two lines the same thing, albeit on different GPIO chips.
> That is currently allowed, and if that happens, the user must
> use topological information about the gpiochip (from sysfs) to
> uniquely identify the GPIO line.
> 
> I wouldn't recommend that since it is essentially inventing a
> problem for oneself to solve, but I don't know what reasons
> people may have to do something like that. There is no technical
> problem with it.

And this may even be unavoidable with dynamic buses such as USB or
greybus, where you can have multiple devices associating the same name
with a pin. That's fine as long as the user-space interface allows for a
way to distinguish them (e.g. through topological information).

Thanks,
Johan