public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ben Nizette <bn@niasdigital.com>
To: Trent Piepho <tpiepho@freescale.com>
Cc: David Brownell <david-b@pacbell.net>,
	lkml <linux-kernel@vger.kernel.org>,
	hartleys <hartleys@visionengravers.com>,
	Mike Frysinger <vapier.adi@gmail.com>,
	Bryan Wu <cooloney@kernel.org>
Subject: Re: [patch/rfc 2.6.25-git] gpio: sysfs interface
Date: Tue, 29 Apr 2008 22:35:26 +1000	[thread overview]
Message-ID: <1209472526.311.50.camel@moss.renham> (raw)
In-Reply-To: <Pine.LNX.4.64.0804282202340.8286@t2.domain.actdsltmp>


On Mon, 2008-04-28 at 22:48 -0700, Trent Piepho wrote:
> On Mon, 28 Apr 2008, David Brownell wrote:
> > On Monday 28 April 2008, Trent Piepho wrote:
> >> On Mon, 28 Apr 2008, David Brownell wrote:
> >>> Simple sysfs interface for GPIOs.
> >>>
> >>>    /sys/class/gpio
> >>>        /gpio-N ... for each exported GPIO #N
> >>
> >> I liked it better they way I had it, "label:N".
> >
> > Those labels may not be available though; or valid in pathnames.
> 
> So just fall back to "gpio" if there is no label?  The only character that's
> not valid in a pathname is '/', so that's trivial to check for.
> 
> const char *label = chip->label && !strchr(chip->label, '/') ?
>  	chip->label : "gpio"; /* or "generic" or "unknown", or ...*/
> 
> This means you don't need a file with number to device assignents.  It makes
> shell scripting a lot easier too.  Say I want the first gpio on a pca9557 gpio
> expander?  It's will be something like:  /sys/class/gpio/pca9557-0:0
> 
> You don't have to worry about dynamic assigments.  You don't have to resort to
> convoluted shell script code to extract the proper range from a mapping file
> and then construct the name.

Sorry if I'm being dense; how do you want this bit to work?  As I see
it, there are a few options:

1) Have the files named as you suggest and all of them always present,
albeit read-only until export.  Very easy to use, easy to discover which
file is which, a decent bit of memory usage having them all listed.

2) Have the files named as you suggest and you have to explicitly
request them or have the kernel explicitly export them.  To request them
yourself you're going to need the gpio number so having the created file
labelled nicely isn't a win over having it labelled with the gpio
number.  I 'spose there's a win for kernel exported gpios, they're more
human readable, but you're still going to have to have the mappings
available somewhere for the manually exported gpios anyway.

3) Have the files named as you suggest, explicit export/request but
better parsing behind the control file so something like
echo "export pca9557-0:5" > control
works.  Very very nice for the user, big heavy back end.

4) Status quo.  Easy, efficient, potentially hard to discover which gpio
you actually want.

My vote's for 1 or 4.  The first one is heavier but easier.  The last
one will need something like the discussed file mapping ranges to gpios.
Do your expectations/ideas fit in cleanly anywhere above?

Thanks,
	--Ben  


  reply	other threads:[~2008-04-29 12:35 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-28 19:39 [patch/rfc 2.6.25-git] gpio: sysfs interface David Brownell
2008-04-28 20:46 ` Andrew Morton
2008-04-28 23:28   ` David Brownell
2008-04-29  2:54     ` Andrew Morton
2008-04-29  3:42       ` Greg KH
2008-04-29 18:45         ` David Brownell
2008-04-29 19:09           ` Andrew Morton
2008-05-02 20:36   ` Pavel Machek
2008-05-17 22:14     ` David Brownell
2008-05-18  0:36       ` [patch 2.6.26-rc2-git] " David Brownell
2008-05-20  7:17         ` Andrew Morton
2008-05-18  4:55       ` [patch/rfc 2.6.25-git] " Ben Nizette
2008-05-19 22:39       ` Pavel Machek
2008-05-20  1:26         ` David Brownell
2008-05-20  8:02           ` Pavel Machek
2008-04-28 23:01 ` Ben Nizette
2008-04-29  0:44   ` David Brownell
2008-04-29  1:58     ` Ben Nizette
2008-04-29  3:44       ` David Brownell
2008-04-29  4:47         ` Ben Nizette
2008-04-29 21:28           ` David Brownell
2008-04-29  6:17         ` Trent Piepho
2008-04-29 22:39           ` David Brownell
2008-04-28 23:09 ` Trent Piepho
2008-04-29  0:45   ` David Brownell
2008-04-29  5:48     ` Trent Piepho
2008-04-29 12:35       ` Ben Nizette [this message]
2008-04-29 18:15         ` Trent Piepho
2008-04-29 21:56           ` David Brownell
2008-04-30  0:49             ` Trent Piepho
2008-04-30 17:49               ` David Brownell
2008-04-29 21:55         ` David Brownell
2008-04-29 23:29           ` Ben Nizette
2008-04-30  1:04             ` David Brownell
2008-04-30  2:08               ` Ben Nizette
2008-04-30  3:13                 ` Trent Piepho
2008-04-30 10:33                   ` Ben Nizette
2008-04-30 17:42                 ` David Brownell
2008-04-30 21:34                   ` [patch/rfc 2.6.25-git v2] " David Brownell
2008-04-30 22:47                     ` Trent Piepho
2008-04-30 23:14                       ` Ben Nizette
2008-05-01  2:12                         ` David Brownell
2008-05-01  2:08                       ` David Brownell
2008-05-01  3:41                         ` Trent Piepho
2008-05-01  4:35                           ` David Brownell
2008-05-01 21:16                             ` Trent Piepho
2008-05-03  2:58                               ` David Brownell
2008-05-03  3:05                               ` David Brownell
2008-04-30 23:28                     ` Ben Nizette
2008-05-01 21:40                       ` David Brownell
2008-04-29  0:47   ` [patch/rfc 2.6.25-git] " Ben Nizette

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=1209472526.311.50.camel@moss.renham \
    --to=bn@niasdigital.com \
    --cc=cooloney@kernel.org \
    --cc=david-b@pacbell.net \
    --cc=hartleys@visionengravers.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tpiepho@freescale.com \
    --cc=vapier.adi@gmail.com \
    /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