Hello Linus, On Wed, Jun 15, 2016 at 08:56:58AM +0200, Linus Walleij wrote: > On Tue, Jun 14, 2016 at 12:03 PM, Uwe Kleine-König > <u.kleine-koenig@xxxxxxxxxxxxxx> wrote: > > > Traditionally the n-th gpio device probed by the omap gpio driver got > > the gpio number range [n*32 .. n*32+31]. > > When order of the devices probed by the driver changes (which can happen > > already now when some devices have a pinctrl and so the first probe > > attempt returns -ENODEV) the numbering changes. > > > > To ensure a deterministical numbering use of_alias_get_id to determine > > the number base for a given device. If no respective alias exists fall > > back to the traditional numbering. > > I'm not too happy about this approach. > > The patch doesn't mention what practical problems it is trying to > solve. the practical problem is that a (binary-only and hardware specific) application uses GPIO47 via /sys/class/gpio and this number refers to the wrong GPIO since I introduced gpio-hogs in the device tree together with pinctrl stuff to make the gpio-hogs work. I agree that this doesn't need to be a reason to care for it from a mainline POV. > The GPIO numbering scheme is a matter of Linux internals and > not about hardware description IMO. Not sure if I should agree here or not. It's very usual that the "internal" gpio numbers match the hardware reference manual. I know this from imx, at91, all pre-dt platforms, I'm sure there are more, and I bet I'm not the only one relying on this for omap. And this is very usual in the dt world, too: $ git grep -El 'gpio. = \&gpio' arch/arm/boot/dts | wc -l 37 > The way forward is to use the character device and use gpiochip > devices with offset indexes and look up GPIOs by name from the > character devices. If nothing substantial happens I am merging the > final pieces of the GPIO chardev ABI for v4.8 and that is doing all that > sysfs was doing and then some. I just need to change a small thing > before sending the final version for review. Hmm, so /sys/class/gpio was obsoleted before the substitution was ready? I'd say an overlapping of several kernel versions would be good as we cannot expect that userspace changes as fast as the kernel. Independent of the inclusion of my patch series in the mainline kernel I'll have to use it on my custom kernel to keep the hardware do what it should. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
