On 16/07/2020 15:38, Linus Walleij wrote: > On Tue, Jul 14, 2020 at 4:01 PM Rodolfo Giometti <giometti@xxxxxxxxxxxx> wrote: > >> I see... however attached is a new version of my proposal patch > > I looked a bit at this! > > IIUC the idea is a "new" sysfs interface that does not require the exporting > etc used by the current "old" sysfs interface. Instead of poking around in > sysfs to export lines we do that from the device tree. Yes. > It also does not use any global GPIO numbers which would be my other > main concern. Exactly, the idea is to have "names" that describe the IO lines to the userspace and a way to fix their usage in each board in the device tree. If a board has a relay line is a non-sense allow users in the userland to use it as an input line. > I must admit that it has some elegance to it. Especially when it comes > to scripting. :) > The problem I see is that lines are left in whatever state they were in > if a script crashes, so there is no "return to the initial value" that was > there when the GPIOs were picked from the device tree. This makes > this a bit fragile. I see but this interface is not designed for such complex usage nor to compete with the current character interface! It is designed to allow boards manufactures to "describe" some I/O lines that are not used by any driver in the device tree, and that users may desire to manage in a very simple manner. Let's thing about relay lines, or just a locked/unlocked input line which can be easily polled. > Also users regularly need to listen to events. This interface can and > should never support that, for this one must use the character device, > which will of course not work in parallel with using this sysfs ABI. > And the day someone wants that we simply have to say no. There > is no way to hold states for event handling in a stateless ABI. > > Well of course they can poll for a line to change, but that is not > proper event handling that reacts to an interrupt. Again, the basic idea is not to compete with the current character interface nor to manage interrupts lines, but just to have a really simple way to describe those I/O lines which at the moment has no name nor references within the device tree. > So while this is much more elegant the old sysfs ABI, and certainly > better for scripting, it still suffers from some conflicts with > the character device, and there is a risk to make users dissatisfied > when they want to e.g. script event handlers. > > What are your thoughts on this? Regarding the event handlers we can add irq supports... however I prefer to keep this interface really simple just to not be confused with the character interface. Ciao, Rodolfo -- GNU/Linux Solutions e-mail: giometti@xxxxxxxxxxxx Linux Device Driver giometti@xxxxxxxx Embedded Systems phone: +39 349 2432127 UNIX programming skype: rodolfo.giometti
