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. > 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.) > 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? > 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? Or am I missing something really obvious here? thanks, greg k-h -- 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
