On Wed, 2 May 2012 14:52:26 -0700 Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, May 02, 2012 at 09:49:01PM +0100, Alan Cox wrote: > > > Actually, why can't you use the GPIO subsystem for something like this? > > > Can't you export your device as both a usb-serial device and a gpio > > > device and have things work properly that way? > > > > You still need the ioctls even then in order to discover the gpio > > numbers > > What discovery? The device knows what gpio values it has in it, and > should be able to register those with the gpio subsystem. You open /dev/ttyUSB0 Ok now in your user application how are you going to find which gpio numbers to use that are associated with this specific port, and how is udev going to do that to manage permissions ? So you need an ioctl to give you the range that is mapped to this (or a sysfs node, but the sysfs node makes the security problem pretty much insoluble) > > and having done that youi've got potential races with unload > > when you try and open them. You've also got permissions considerations > > and synchronization between gpio and data problems. > > That can be handled in the driver itself, if it really is a problem (the > existing patch sure didn't handle any of that at all, so I'm guessing > either it wasn't considered, or it isn't a problem.) Not reliably open /dev/ttyUSB0 [or sysfs node] read gpio numbers close open gpio foo Oh dear... so random shell scripting user is going to screw up horribly. > > It's not a good way to go. It might make sense in some platforms to > > expose them as both but its not a good general model. > > Why isn't the gpio subsystem a good general model? I thought that is > what it was created to solve? gpio provides a flat abstraction for arbitary pins on a platform. It's really oriented to fairly fixed system stuff. It doesn't provide a useful abstraction for extra carrier lines. Imagine if RTS and DTR were driven by GPIO pins instead of the tty layer. Many devices use them as extra magic GPIO lines not as tty control lines, so its an equivalent argument. > > I'm currently favouring adding some 'additional control line' bits to > > termiox. > > Yes, but that's only good for usb-serial devices that also have gpio > pins on the controller side. Which seems pretty limited to me. > > If I have a userspace program, and I want to use GPIO, I shouldn't have > to care/know that the pins are really on the end of a USB->serial > bridge, or somewhere hanging off of a SOC, the same userspace api should > "just work", right? For certain applications that makes more sense, which is why I said you may well want to expose it as both. However you still need both, and ideally we need a standardised pattern of assignments for line disciplines that use the extra control lines (which has come up recently for another device with extra lines) I think it basically boils down to this If you have a serial port with some gpio lines that drive arbitary unrelated electronics then the gpio interface is handy because you can use the same code logic as if it was wired to other pins elsewhere If you are using them as part of the tty interface as extra control lines (eg for smartcard protocols) then you want them driven via the tty interface and doubly so once we add some of the smartcard/sim ldisc support. Hence we really need to expose them both ways because end users are doing both things with the gpio pins on these ports. So I'd suggest we expose them via termiox bits and also via the tty providing gpio range info in a standardised way. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
