Messages in this thread | | | Subject | Re: [patch/rfc 2.6.25-git] gpio: sysfs interface | From | Ben Nizette <> | Date | Wed, 30 Apr 2008 12:08:11 +1000 |
| |
On Tue, 2008-04-29 at 18:04 -0700, David Brownell wrote: > 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.
| |