[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1227810026.4277.48.camel@aiko.keithp.com>
Date: Thu, 27 Nov 2008 10:20:26 -0800
From: Keith Packard <keithp@...thp.com>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: keithp@...thp.com, linux-kernel@...r.kernel.org,
Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: [PATCH] usb/serial/cp2101: Add support for cp2103 GPIO pins
On Thu, 2008-11-27 at 10:58 +0000, Alan Cox wrote:
> Only concern I have is that a custom ioctl means every time a new serial
> chip grows GPIO pins we end up with more ioctls.
I'm not sure we'll find a lot of serial chips with GPIO pins attached...
> We have an LED class driver which might perhaps do the job but isn't
> really oriented that way but would keep the tty and gpio pins separate
> and available to different applications at the same time.
Yeah, I wondered about doing it that way, although not using the LED
driver as GPIO is bi-directional. There is an existing GPIO subsystem
which makes gpios available within the kernel, but does not expose them
up to user land except through the /sys/class interface.
> Failing that a rename to make it a generic tty gpio ioctl might be more
> futurerpoof ?
Perhaps exposing the existing gpio kernel infrastructure into /dev in
some fashion would make sense? We'd have to create some kind of
'protocol' for the write operation that would mark which bits to change,
and perhaps some way of explicitly setting pins to tri-state.
That would have the benefit of making gpio-based drivers possible from
user-mode, which is exactly what I'm doing here (building an interface
to the debug port on a cc1111 chip).
--
keith.packard@...el.com
Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)
Powered by blists - more mailing lists