public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Keith Packard <keithp@keithp.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: keithp@keithp.com, linux-kernel@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@suse.de>
Subject: Re: [PATCH] usb/serial/cp2101: Add support for cp2103 GPIO pins
Date: Thu, 27 Nov 2008 10:20:26 -0800	[thread overview]
Message-ID: <1227810026.4277.48.camel@aiko.keithp.com> (raw)
In-Reply-To: <20081127105823.30786bf4@lxorguk.ukuu.org.uk>

[-- Attachment #1: Type: text/plain, Size: 1326 bytes --]

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@intel.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2008-11-27 18:21 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-27  8:29 [PATCH] usb/serial: Add compat_ioctl pass-through Keith Packard
2008-11-27  8:29 ` [PATCH] usb/serial/cp2101: Add support for cp2103 GPIO pins Keith Packard
2008-11-27 10:58   ` Alan Cox
2008-11-27 18:20     ` Keith Packard [this message]
2008-11-27 18:41       ` Greg KH
2008-11-28  1:31         ` Keith Packard
2008-12-03  7:12           ` Greg KH
2008-12-03  8:11             ` Keith Packard
2008-11-27 14:31 ` [PATCH] usb/serial: Add compat_ioctl pass-through Arnd Bergmann
2008-11-27 18:27   ` Keith Packard
2008-11-28 11:43     ` Arnd Bergmann
2008-11-28 14:03       ` Alan Cox
2008-11-28 15:42         ` Arnd Bergmann
2008-11-28 22:28           ` Keith Packard
2008-11-28 22:33             ` Alan Cox
2008-11-29  1:02               ` Keith Packard
2008-11-29  1:10                 ` Alan Cox
2008-11-29  1:23                   ` Arjan van de Ven
2008-11-29  1:37                     ` Alan Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1227810026.4277.48.camel@aiko.keithp.com \
    --to=keithp@keithp.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox