Message-ID: <20120502222728.GA2871@kroah.com>
Date:	Wed, 2 May 2012 15:27:28 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Preston Fick <pffick@...il.com>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org,
	preston.fick@...abs.com
Subject: Re: [PATCH 3/3] usb: cp210x: Add ioctl for GPIO support

On Wed, May 02, 2012 at 11:10:27PM +0100, Alan Cox wrote:
> On Wed, 2 May 2012 14:52:26 -0700
> Greg KH <gregkh@...uxfoundation.org> 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,

Just look at the gpio device that has ttyUSB0 as its parent.

> and how is udev going to do that to manage permissions ?

How does udev handle permissions for gpio devices today?

> 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)

range for what?  Doesn't the gpio interfac provide the size of the gpio
registers to userspace?

As for security, how is that handled today with gpio devices?

> > > 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.

What's the odds that the data going across the tty link corrisponds with
the gpio control?

And shell scripting the gpio interface is used today, I've seen it on
the beaglebone machine.

> > > 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.

Ok, fair enough, but RTS and DTR are "well defined" as part of the RS232
specs, and handle flow of the data itself.  These gpio lines are not tty
control, but as you point out, used for other things, so keeping them
separate from the tty node seems to make sense to me.

> > > 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.

Ok, I'll wait for your proposed standardised way before complaining any
more :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists