Messages in this thread | | | From | David Brownell <> | Subject | Re: [patch/rfc 2.6.25-git] gpio: sysfs interface | Date | Wed, 30 Apr 2008 10:42:42 -0700 |
| |
On Tuesday 29 April 2008, Ben Nizette wrote: > > 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)
Make that range X to X + ngpio - 1, of course. :)
> > /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.
What I have working right now is like the original patch, but with "gpiochipN" (and "gpioN") nodes. The "*-N" style doesn't match other sysfs usage.
So the "control" and "gpioN" files aren't nesting like that.
It could be argued which feels more natural. For external gpiochips it might feel more natural to nest the gpioN nodes. On some SOCs, that also true of the integrated GPIOs (docs refer to "PB29" highlighting port B bit 29). But on many others (OMAP and PXA for starters), they're referenced in docs by a number 0..hundreds, ignoring details like which register bank holds the relevant control bits.
That's why I decided not to use nesting. Either choice can seem a bit odd on some platform; this way is easier and takes less kernel code.
- Dave
| |