Re: [PATCH 3/3] usb: cp210x: Add ioctl for GPIO support

[Alan Cox]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/