On Tue, 2008-04-29 at 18:04 -0700, David Brownell wrote:
quoted text
> On Tuesday 29 April 2008, Ben Nizette wrote:
> > I guess one last option (which is made hard by chip label non-uniqueness
> > but I'll throw out anyway) would be
> > 
> > /sys/class/gpio
> >         /chipa
> >                 /gpio-n
> >                         /value
> >                         /direction
> >                 /control
> >         /chipb
> >                 :
> >                 :
> > 
> 
> Or maybe:
> 
>   /sys/class/gpio
> 	/gpiochip-X			<-- range X..(X+ngpio)
> 		/device			<-- symlink, if it's known
> 		/ngpio
> 		/label
> 		/start			<-- maybe; start == X
> 
> with the gpio-N links probably going where you showed.  That'd be
> best in terms of Purity Of Essence.

So you're suggesting that the gpio-N links and control file live inside
the gpiochip-X folder along with info about the chip to which they're
attached?  I don't mind this, sounds good.  Certainly feels most
sysfsish.

Scripting would be pretty simple assuming there's one control file per
chip and the gpio number written to said control file is relative to
that chip's base.  i.e. finding pcf9557:5 (assuming only one such
device) would just be

- find the gpiochip-X folder whose /label == pcf9557
- echo "export 5" > <that_folder>/control
- read/write <that_folder>/gpio-5/{value,direction}

If you've got multiple pca9557s then you're always going to have a hard
time distinguishing them but you've been given all the information
available to allow you to discover which is which.

In fact more than enough; if the base is dynamically allocated then you
don't know what to expect /start to be, you know what /ngpio will be and
you never need to find the full gpio number so those 2 files are
redundant yeah?

--Ben.

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