On Wed, Jul 06, 2016 at 02:34:39PM +0200, Linus Walleij wrote:

On Wed, Jul 6, 2016 at 12:27 PM, Johan Hovold [off-list ref] wrote:

quoted

On Wed, Jul 06, 2016 at 11:34:37AM +0200, Linus Walleij wrote:

quoted

quoted

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?

quoted

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