On Tuesday 29 April 2008, Ben Nizette wrote:
quoted text
> 
> 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.  :)

quoted text
> > 		/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
--
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/