On Mon, May 4, 2015 at 10:49 AM, Johan Hovold <johan@xxxxxxxxxx> wrote: > On Mon, Apr 13, 2015 at 01:05:15PM +0200, Martin Fuzzey wrote: >> The above means that, in order to export the GPIO to userspace via >> /sys/class/gpio/export the userspace code must know the exact hardware and >> kernel version information. > > Not quite. You can still determine the gpio number in the above cases by > walking the sysfs tree to find the chip and it's base. This is the only > way to do this for dynamic buses such as USB. Maybe we should start providing something like an "lsgpio" utility in tools/gpio to do this, just as a hint to userspace people on how things should be done. >> This patch series solves both problems by performing the external >> signal => GPIO mapping in the device tree. > > As Rob already mentioned, what we want is some way to declare pin > functions. These could then be requested from userspace (or used in DT, > something which should allow for further refactoring there as well) > unless a driver has already claimed them. We have the ability to name the GPIO lines (I usually refer to lines rather than pins, as pins are physical and not all GPIOs are, actually) using the array "names" in struct gpio_chip, however this has no DT binding, so maybe people should work on that. These names appear as named line files in sysfs IIRC. Or maybe you're thinking of something else? > We don't want to add more dependencies on the current sysfs-based > interface, which I hope we'll one day will be able to retire in favour > of a more sane one. Agree. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
