As you know we froze the GPIO sysfs ABI in kernel v4.6 and now we need to complete its replacement with a new mechanism using the character device. We can currently: - Enumerate gpiochips - udev/systemd and its siblings will do this automatically from the character devices (a patch for mdev will be needed for BusyBox to enumerate the chips). - List its lines with name and consumer strings, that is what "lsgpio" from tools/gpio/lsgpio.c does. - Locate the offset of any desired GPIO line from this string - Locate the gpiochip in the bus topology using sysfs (as with any device) So I need some help, rants, ACKs etc on whatever I come up with next, and the next steps are (from the top of my head): - Naming GPIO lines from DT files (So you have something reasonable to look for from userspace) What do people think about just using gpio-names = "foo", "bar", "baz"; as suggested by Rob Herring? - Getting a filehandle for one or several GPIOs I would prefer to support getting multiple GPIOs from day one as we know this is going to be a usecase sooner or later. For example it is not uncommon to bitbang a bus from userspace and then clock and data lines should - Give them consumer names from userspace (label who's using this GPIO) - Setting flags on a line from userspace (such as ACTIVE_LOW or OPEN_DRAIN) so the hardware can act accordingly. - Using this filehandle, shake the lines from low to high and vice versa from userspace. - Getting a filehandle to listen to input events (interrupts) from a certain GPIO line. Here I am primarily thinking about something akin to IIO's event mechanism using poll() which I like a lot. - Getting the filehandle for events involves selecting trigger type for rising/falling edge events. (I don't see how userspace could possibly support or want to support level IRQs.) I am thinking about using filehandles to get a grip on (multiple) GPIOs and for events because it has the nice property that we know very well when userspace is using the resource, and we can free it when the file is closed (which also happens if the application crashes or get killed, or at shutdown etc). I'm thinking about staying with a single open() on the chardev from userspace, but several processes can open handles, then we need to use an ioctl() to say what we want from this filehandle: whether a handle on a few GPIO lines or a polled event. We want to be mutually exclusive to processes when getting pins for output, while making it possible for several clients to read the same line or subscribe to events from the same line. Your thoughts? 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
