linux-kernel - Re: [patch/rfc 2.6.25-git] gpio: sysfs interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 30 Apr 2008 10:42:42 -0700
From:	David Brownell <david-b@...bell.net>
To:	Ben Nizette <bn@...sdigital.com>
Cc:	Trent Piepho <tpiepho@...escale.com>,
	lkml <linux-kernel@...r.kernel.org>,
	hartleys <hartleys@...ionengravers.com>,
	Mike Frysinger <vapier.adi@...il.com>,
	Bryan Wu <cooloney@...nel.org>
Subject: Re: [patch/rfc 2.6.25-git] gpio: sysfs interface

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