lkml.org 
[lkml]   [2008]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [patch/rfc 2.6.25-git] gpio: sysfs interface
    From
    Date

    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



    \
     
     \ /
      Last update: 2008-04-29 14:39    [W:4.646 / U:0.112 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site