Simple sysfs interface for GPIOs.
    /sys/class/gpio

        /gpio-N ... for each exported GPIO #N

	    /value ... always readable, writes fail except for output GPIOs

	    /direction ... writable as: in, out (default low), high, low

    	/control ... to request a GPIO be exported or unexported
GPIOs may be exported by kernel code using gpio_export(), which should

be most useful for driver debugging.  Userspace may also ask that they

be exported by writing to the sysfs control file, helping to cope with

incomplete board support:
  echo "export 23" > /sys/class/gpio/control

	... will gpio_request(23, "sysfs") and gpio_export(23); use

	/sys/class/gpio/gpio-23/direction to configure it.

  echo "unexport 23" > /sys/class/gpio/control

	... will gpio_free(23)
The D-space footprint is negligible, except for the sysfs resources

associated with each exported GPIO.  The additional I-space footprint

is about half of the current size of gpiolib.  No /dev node creation

involved, and no "udev" support is needed.
This adds a device pointer to "struct gpio_chip".  When GPIO providers

initialize that, sysfs gpio class devices become children of that device

instead of being "virtual" devices.  The (few) gpio_chip providers which

have such a device node have been updated.  (Some also needed to update

their module "owner" field ... for which missing kerneldoc was added.)
Based on a patch from Trent Piepho <tpiepho@freescale.com>, and comments

from various folk including Hartley Sweeten.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

---

 arch/avr32/mach-at32ap/pio.c |    2

 drivers/gpio/Kconfig         |   16 ++

 drivers/gpio/gpiolib.c       |  281 +++++++++++++++++++++++++++++++++++++++++++

 drivers/gpio/mcp23s08.c      |    1

 drivers/gpio/pca953x.c       |    1

 drivers/gpio/pcf857x.c       |    1

 drivers/i2c/chips/tps65010.c |    2

 drivers/mfd/htc-egpio.c      |    2

 include/asm-generic/gpio.h   |   28 ++++

 9 files changed, 333 inser...
[ message continues ]

I liked it better they way I had it, "label:N".
When you have multiple GPIO sources, it's a lot easier to see where they are

comming from if they use the chip label.  Especially if support for dynamic
You took away the code for the label field?  That was one of the features of

my code that Ben Nizette mentioned as an advantage over a char-device
I don't see what's wrong with having devices add to gpiolib create a device

for the gpio's to be the children of.  You said that some devices can't do

this, but I don't see the difficulty.
platform_device_register_simple("my-gpio", 0, NULL, 0);
Maybe you could simplify the text parsing by having positive gpio numbers

export the gpio and negative numbers un-export the gpio?  Then there would not

be any need to parse a command with arguments.

--

If all gpios are exported read only by default then keeping the label

either in the folder naming or as a file is certainly useful to identify

what you actually want to talk to.  If you're debugging a driver or

you've already manually exported a gpio then I'd assume you already know

pretty much all you need to know about that pin.
	--Ben.
--

I'd rather see such stuff in a "chip_label" attribute.  Easy enough to
Since it's not always available, I removed it.  Note that you're

talking about the label passed to gpio_request() here, not the one

applied to the gpio_chip.  I could restore this as a "gpio_label"

attribute, that's not always present ... but I'd rather not have
Typical SOC based systems have up to a few hundred pins that could

be used as GPIOs.  The number actually used as GPIOs is rarely more

than a dozen or two, with other pins generally muxed to a peripheral

function ... or not even connected.
It can't know where in the device tree to put such device nodes,

or how to implement operations like suspend() and resume() for

such nodes.  Creating such nodes, and their drivers, is NOT a role
Most GPIOs come from platform code that doesn't create such a device

today.  In cases like OMAP, GPIOs are usable even before memory

allocations can work, so creating and using device nodes for GPIO

controllers would involve updating code running VERY early in boot...
You're free to write patches creating such device nodes, and work

with the platform maintainers to convert their GPIO support to use
Some were on-list, some were off-list.  The comments have been

coming off and on for a few years now, so I'm certain you would
I had that thought too.  Even though I think that solution

is kind o fugly.  ;)
If need be, that can be changed.
- Dave

--

So just fall back to "gpio" if there is no label?  The only character that's

not valid in a pathname is '/', so that's trivial to check for.
const char *label = chip->label && !strchr(chip->label, '/') ?

 	chip->label : "gpio"; /* or "generic" or "unknown", or ...*/
This means you don't need a file with number to device assignents.  It makes

shell scripting a lot easier too.  Say I want the first gpio on a pca9557 gpio

expander?  It's will be something like:  /sys/class/gpio/pca9557-0:0
You don't have to worry about dynamic assigments.  You don't have to resort to

convoluted shell script code to extract the proper range from a mapping file
It's nice to be able to see what a driver is using a gpio for.  You could also
So make them appear when something in the kernel requests them, explictly

exports them to user-space, or they are requested from user space.  The last

two can offer write access, the first only read.  I don't see why the explicit

request is necessary for something to show up in sysfs.  Nothing else in sysfs

seems to work this way.  At least, I see plenty of files in there that I
$ ls /sys/class/tty/ | wc

     579     579    4042
I didn't mean for gpiolib to create that device, that's obviously wrong.  What

I meant was the platform code, e.g. the code the calls gpiochip_add(), could

just call that one function and then it would have a device for the gpios to

appear under in sysfs.  You said that many systems "can't" have a device for

the gpios and I don't see how this is so.  Could you give me an example of

something that calls gpiochip_add() and can't provide a dev field in the
If memory allocations don't work, then gpiochip_add() can't possibly do

anything with sysfs, so having a device to parent the sysfs files from is a
I thought you meant comments to my patch.

--

Sorry if I'm being dense; how do you want this bit to work?  As I see

it, there are a few options:
1) Have the files named as you suggest and all of them always present,

albeit read-only until export.  Very easy to use, easy to discover which

file is which, a decent bit of memory usage having them all listed.
2) Have the files named as you suggest and you have to explicitly

request them or have the kernel explicitly export them.  To request them

yourself you're going to need the gpio number so having the created file

labelled nicely isn't a win over having it labelled with the gpio

number.  I 'spose there's a win for kernel exported gpios, they're more

human readable, but you're still going to have to have the mappings

available somewhere for the manually exported gpios anyway.
3) Have the files named as you suggest, explicit export/request but

better parsing behind the control file so something like

echo "export pca9557-0:5" > control

works.  Very very nice for the user, big heavy back end.
4) Status quo.  Easy, efficient, potentially hard to discover which gpio

you actually want.
My vote's for 1 or 4.  The first one is heavier but easier.  The last

one will need something like the discussed file mapping ranges to gpios.

Do your expectations/ideas fit in cleanly anywhere above?
Thanks,

	--Ben  
--

My vote is for #4 with a chip listing file.
I don't like the hacked names ... none of the other /sys/class/*/name

files on any of my systems use hacked names.  The entire motivation for

name hacking seems wrong to me, and by observation it's been rejected

for all other class names.
- Dave
--

Right, agreed.
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

		:

		:
I guess this doesn't gain much over labelling files chipname:N (and has

the same pitfalls) but does at least seem less hackish.
--

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.
- Dave
--

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.
--

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

--

Simple sysfs interface for GPIOs.
    /sys/class/gpio

    	/control ... to request a GPIO be imported or returned

        /gpioN ... for each exported GPIO #N

	    /value ... always readable, writes fail for input GPIOs

	    /direction ... r/w as: in, out (default low); write high, low

	/gpiochipN ... for each gpiochip; #N is its first GPIO

	    /base ... (r/o) same as N

	    /label ... (r/o) descriptive, not necessarily unique

	    /ngpio ... (r/o) number of GPIOs; numbered N .. N+(ngpio - 1)
GPIOs may be exported by kernel code using gpio_export(), which should

be most useful for driver debugging.  Userspace may also ask that they

be imported by writing to the sysfs control file, helping to cope with

incomplete board support:
  echo "23" > /sys/class/gpio/control

	... will gpio_request(23, "sysfs") and gpio_export(23); use

	/sys/class/gpio/gpio-23/direction to configure it.

  echo "-23" > /sys/class/gpio/control

	... will gpio_free(23)
The extra D-space footprint is a few hundred bytes, except for the sysfs

resources associated with each exported GPIO.  The additional I-space

footprint is about two thirds of the current size of gpiolib (!).  Since

no /dev node creation is involved, no "udev" support is needed.
This adds a device pointer to "struct gpio_chip".  When GPIO providers

initialize that, sysfs gpio class devices become children of that device

instead of being "virtual" devices.  The (few) gpio_chip providers which

have such a device node have been updated.  (Some also needed to update

their module "owner" field ... for which missing kerneldoc was added.)
Based on a patch from Trent Piepho <tpiepho@freescale.com>, and comments

from various folk including most recently Hartley Sweeten and Ben Nizette.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

---

Notable updates from previous version:  doc update, mutex protection

for sysfs access, export basic gpio_chip info ("what GPIOs exist"),

depend on new sysfs_streq() call, si...
[ message continues ]

You dropped the 'device' symlink?  Sure it won't always be available but

I did quite like the idea of being able to walk back through sysfs and
--

Just didn't describe it in that summary ... like several other

standard attributes, like "uevent" and "subsystem".  The only

thing different about "device" is that when the gpio_chip doesn't

say what device it uses, that will (necessarily) be missing.
Yeah, gotta fix that.  Unfortunately "-0" == "0" ... I'll have to

handle any leading "-" by hand.  Trivial fix, in all.
- Dave
--

"simple"?  What I had was a lot simpler.
So, I want to set gpio 5 on a pcf9557 extender.
cat 1 > /sys/class/gpio/pcf9557-0:0
But now I can't do this anymore, it has to be harder.  So how do I do it?  It

doesn't seem very considerate to ignore the real use cases of the person who
I have a JTAG interface implemented via GPIOs.  With my system, one can see

the gpios used in sysfs with the proper labels (TCK, TDO, TDI, etc.).  This is

very helpful for people connecting something to the interface to know they

have the write gpio lines connected.  What's the point of allowing

one to label gpio lines if it's not going to be easy to see?
It also means that if they have trouble getting what their connecting to work,

they can always control the line via sysfs and see with a probe that it

changes.  They can raise TRST (which they know is the right line from the

label) and see the system reset.
Adding gpio_export() calls to the kernel source and recompiling and

re-flashing just isn't going to happen for a large portion of users.
So if a driver is already using gpio 23, then there is no way to see it in
So if a driver was already using gpio 23 and you wanted to look at it from

userspace, you'll free it from both sysfs and the driver that was using it
You could say the same about 90% of the writable files in sysfs.

--

But it had some "must fix" problems, which I told you when you

posted your first patch.  You didn't fix them.  And since then,

your pushback seems to rely very heavily on ignoring issues I

pointed out are "must fix" or "can't/doesn't work that way".
Which isn't exactly where most folk start.  If it's something

done routinely, they'll likely have a script to run; either

the native language type, or something for bash or Python.
If it's a one-off, they probably start from schematics and

are fully capable of adding 5 to the base number associated

with the particular pcf chip in question (say, the third one

on this card stack) ... and doing the same for other pins

they need to diddle.  Note taking is always a good practice

when sorting out such issues, but adding five is in your head
"Any more"?  You never *could* do that before.  The original

patch you sent didn't do that, and the last code snippet I
I didn't ignore *use cases* at all.  You can certainly set

the value of such a GPIO with the $SUBJECT interface.
Just ... not using that syntax.  Use cases are several steps
I've seen at least half a dozen different userspace models for

how to work with GPIOs.  You didn't write all of them.  Nor
Right.  If that driver wanted to cope with userspace mucking

around with its internal state (GPIOs) it would have explicitly

enabled it by calling gpio_export().  If it's not prepared to

cope with the various flavors of breakage that would facilitate,
No, that was the one-line summary.  It's only freed if it was

originally requested from userspace (by "echo 23 > control").

As you can see in the code...
- Dave
--

So what are these must fix problems?  You don't want all the gpios to appear

in sysfs by default in case there are many.  So have them only appear when

they are requested by something.  Problem solved.
Someone might label the chip with a label using a '/'.  First of all, that's

nothing but speculation on a problem that will probably never happen.  Do any

existing chip labels use a '/'?  Is it really that hard to just not label the

chip that way?  But suppose someone just can't avoid it, one line of code,

that I posted, is all it takes to fix this.
Multiple chips with the same label.  That's more annoying, but still

easy to fix in a number of ways:

1) If the label isn't unique, don't register that chip with sysfs.

2) If the label isn't unique, appended a suffix to make it so.

3) Always add a sequence number the end of the chip label.  This is quite

common in fact.
The sysfs control interface won't be able to handle gpios named this way.  Or

doing so will be "too hard".  Not true, I wrote and posted code that did it.

It was simpler than the initial code you wrote for the control interface, and

much simpler than the latest with all the gpiochip stuff.  BTW, my code also

worked for unexporting gpio 0....
You say nothing in sysfs works this way, but I don't agree.  Take a look at

/sys/class/net, you have names like "tap0", "eth0", "eth1", "lo", etc.  This

is exactly what I'm saying to do.  The first "eth" gpio chip you register is

appears as eth0 in sysfs, the second as eth1, and so on.
The directories are not just named "netdev0", "netdev1", "netdev2", with some

sort of mapping file telling you ethernet devices are using numbers 2-3.
Look at PCI, you have files like "/sys/bus/pci/devices/0000:01:05.0" and

"/bus/pci/devices/0000:00:0d.2".  It's not "pci1", "pci2", "pci3", with a

"bus0" directory telling you that the bus starts at device 3 and has 6

devices.
Look at ACPI, it's /sys/bus/acpi/devices/{LNXSLPBN:00,LNXPWRBN:00,LNXSYSTM:00}

and "device:00", "device:01".  It use...
[ message continues ]

Not fixed in any update you sent to your original patch, in

the past three weeks, that's the key point.  In particular,

the number one issue was completely ignored.  (Your recent
So, when I said that sysfs doesn't use names like "gpio-19" but instead

uses names like "gpio19" ... exactly what don't you agree with?
Your examples prove what I *did* say.  I don't know who you're trying
Which is fine.  The $SUBJECT patch provides a simple solution for it.

As well as for the other use cases I sketched.  With identifiers that
Those are *NOT* my words.  Again, I don't know what straw man you

are arguing with, but please stop painting my face on it, putting

your words in its mouth, and using that to claim you're disproving

something I've "said" (but haven't).
I did say your problem could be solved ... but with different
Right, and since I *can* do stuff like that in busybox with ASH,

that quickly, I hope you'll agree your flamage has been blowing
Userspace being able to MODIFY the direction and output value
It's a question of how easy you make it to break things.

You seem to draw the "too easy" line differently than I do.

I don't want *anything* else mucking around with state my

drivers are responsible for managing.
--

Let's be fair about who was waiting for who.  You didn't like some things

about my original system, I proposed changes here,

http://article.gmane.org/gmane.linux.kernel/662862, on April 7th.  You didn't

respond until April 27th, then decided to take my patch and change it they way
Instead of gpio19, it should be the chip label followed by 19.  I want "eth0",

"tap0".  You want "net0", "net1", and then a whole extra system to figure out
 	"However, I think a slightly more common practice in current embedded

 	Linux systems is to build custom kernels that know which

 	daughtercard(s) are available.  That's mostly what gets pushed

 	upstream, anyway..."
 	"Which is why this particular side-argument seems like a waste of time

 	to me:"
 	because for a pure userspace interace it can't be helpful unless

 	userspace makes the labels:
I just don't see that.  I've got a JTAG interface on the gpio pins.  The user

wants to see what gpio pin is assigned to what function.  The information

could be right there with the direction and value.  They could have a script

that searches the gpios for one with a matching label.
I've got a board revision that so far the kernel doesn't care about.  I

could put something like this in my init scripts:

for i in 0 1 2 3

do

    echo "Board Rev [bit $i]" > /sys/class/gpio/pca9557-1:$i/label

done
Yes, I could only have the information in some docs and force someone to look
Now you're the one with the straw-man.  I've proposed many times that gpios

that have been requested by anything be exported READ-ONLY automatically.  I

said "*seeing* the value", not "*changing* the value".  I've yet to see you
Will allowing userspace to request a gpio used by the kernel allow one to break

things easier than:

cat /dev/zero > /dev/hda
I don't think so.  Do you think allowing root to use a gpio after root has

specifically exported it will allow someone to break their system more easily

and to a greater extent than that command?  Yet that command...
[ message continues ]

I think that's because it's a trivial "Shell Programming 101"

homework assignment, and we have a general policy against doing

people's schoolwork for them ...
Here are two clues for you:  "for DIR in gpiochip*"; and then

"LABEL=$(cat $DIR/label)".  I'm quite certain that if you put

aside your demonstrably strong desire to flame, you can solve

that little problem.
Or perhaps the issue here is just bikeshedding.  Regardless,

the signal-to-noise ratio is way too low..

--

Hmm, maybe that was buried in the volume of other stuff you

posted ... this is the first time I recall your mentioning

read-only exports.  Or limiting exports like that.  Certainly

no code I've seen from you worked like that.
What I recall was your original approach of exporting absolutely

everything -- hundreds of (potential) GPIOs, even pins that

were configured for other purposes.
I don't have any particular objection to exporting things

readonly.  Maybe you noticed the comment in my patches that

suggesting such an export mode might be useful.  But I'd

rather not export things that don't need exporting, and

bias things towards low per-gpio costs.
It's easy to add features later, if they turn out to be needed.

But removing interfaces is very hard ... which is another reason

I'm not very receptive to all those bells'n'whistles you propose.

--

We've discussed the down sides of your model.  It's got up sides, eg

your use case is made very easy, but it ain't all roses.
Now, if the kernel has requested that pin and hasn't exported it you

can't touch it.  This is what we want.
Otherwise you will walk the gpiochips, find your chip's base and use it

to calculate the gpio number.  If the kernel's exported it then the file

will be there to use.  If the kernel hasn't requested it then you can do

so by using the control file.
Yes it's longer and harder and more convoluted.  It's also much more
That label was always just supposed to be a debugging aid, i.e.

something to show up in debugfs.  This is used to reduce D footprint.

Maybe if the labels are being stored anyway they can be made available
That's very useful indeed, but if you don't want userspace to be able to

do that it's also dangerous.  This is why the kernel has to explicitly
So you want userspace to be able to clobber any gpio which is used by

the kernel?  That's what this version of the interface is designed to
The way to see it in sysfs is to have the kernel export it.  This is the

point.  The kernel should request it for it's own use then export it if
If driver was using it, it will have requested it.  If you are looking

at it then the kernel must have also exported it.  If the kernel's

exported it then nothing you can do will unexport it.  You can only

unexport gpios you've exported yourself manually and the only gpios you

--

They could be; I've had code to do it.  It never stays in

very long, because for a pure userspace interace it can't

be helpful unless userspace makes the labels:  the labels

displayed otherwise just reuse the same constant.
For a "kernel cooperates with userspace" model that might

be more useful.  And I've certainly found the debugfs info

hard to interpret without such labels!!  But Trent has

said he doesn't see anyone modifying enough code to adopt

such a "cooperates" model.  Which is why this particular

side-argument seems like a waste of time to me:  even he

has not proposed the key change his argument depends on.
The original control file syntax I thought about was
	export NN mode label
where it would gpio_request(NN, "label") and then set the

direction (and maybe value) according to "mode".  But that

was just a PITA to cope with ... so it's now been trimmed

down to just "NN" (and "-NN").
- Dave
--

I don't suppose you could actually write the code to do this?
I already wrote the code, and am using it, for the way I have it work.
cat /sys/class/gpio/pcf9557-0:5
But I guess this is too easy.  "We can't have any of that!!  The Earth will

turn in its grave!  And Slashdot will be decorated in Pink!  Teh End Daze

arrive!  :)"
--

I'm sure I could but I'd prefer to have us all come (as close as

possible) to an agreed theoretical interface first :-)
What you've got working there is nice but it still downsides (unless you

can set me straight).  First, we still have the problem of either 100s

of unused files or an index to use in a request.  Also, if you've got

many pcf9557s in a system you'll have a bunch of pcf9557-n; how do you

know which is which?
I think with the above solution we're coming very close to a sexy

system.  We don't need an index file, we have all the information we

need to find which device is which, there's no need to calculate any

full gpio number, there's no files which aren't going to be used, it's

safe, extensible, scriptable, sysfsish..  Am I missing anything?
--Ben

--

Well, is it really that much?  There are 579 files under /sys/class/tty.  But
The back end doesn't seem that big to me.  Here's code for it.  If anything,

the parsing code is simpler than what David has.  It's certainly not huge.

David's code for parsing the control file plus code for generating a mapping

range file would certainly be larger.
/* Format:  -?(chiplabel:)?number

  * The optional leading - unexports the gpio, without it the gpio is exported.

  * The optional chip label followed by a : gives you the Nth gpio of that

  * chip.  With no label you get gpio "number".

  */
static ssize_t control_store(struct class *class, const char *buf, size_t len)

{

 	const char *numstr;

 	unsigned long num;

 	int mode = 0;
 	if (buf[0] == '-') { /* un-export? */

 		mode = 1;

 		buf++;

 	}
 	numstr = strrchr(buf, ':');
 	/* Get GPIO number */

 	if (strict_strtoul(numstr ? numstr + 1 : buf, 0, &num))

 		return -EINVAL;
 	/* Match chip label, if one was specified */

 	if (numstr) {

 		/* No + 1 in len to not include the ':' at the end */

 		int i, len = numstr - buf;

 		const struct gpio_chip *chip = NULL;
 		for (i = 0; gpio_is_valid(i); i++) {

 			if (chip == gpio_desc[i].chip)

 				continue;

 			chip = gpio_desc[i].chip;

 			if (!chip)

 				continue;
 			if (!strncmp(buf, chip->label, len) &&

 			    chip->label[len] == '\0')

 				goto found_chip;

 		}

 		return -EINVAL;

found_chip:

 		if (num >= chip->ngpio)

 			return -EINVAL;

 		num += chip->base;

 	}
 	if (mode) {

 		/* Unexport */

 		if (!gpio_is_valid(num))

 			return -EINVAL;

 		if (!test_and_clear_bit(FLAG_SYSFS, &gpio_desc[num].flags))

 			return -EINVAL;
 		gpio_free(num);

 	} else {

 		/* Export */

 		int status = gpio_request(num, "sysfs");
 		if (status < 0)

 			return status;
 		status = gpio_export(num);

 		if (status < 0) {

 			gpio_free(num);

 			return status;

 		}
 		set_bit(FLAG_SYSFS, &gpio_desc[num].flags);

 	}
...
[ message continues ]

I just ssh'd into three embedded boards I have handy, and they have

respectively four, four, and seven entries there.  That "seven"

case is actually incorrect ... the other three serial ports aren't

connected to anything.
So:  yes, adding a few hundred useless sysfs nodes *IS* a problem

in the target environment of embedded boards.
Note that "read-only until export" is far from straightforward
Apples vs oranges.  Use the same command syntax if you're going

to make comparisons; I can save even more with "+export/-unexport"
The #3 option presumes some file listing chips and ranges too,

since GPIOs are exported only on demand.  Ditto #2 and #4...
- Dave
--

If the code you wrote it not too complex, then why is the code I wrote, which
You never answered how one was supposed to get the proper device from a

script.

--

Well, Andrew *did* object to the complexity.  But that wasn't

the point I was making there:  you were comparing apples and

oranges ... which makes it particularly easy to reach desired
No I didn't.  But that's why I liked Ben's suggestion of creating

sysfs nodes for each gpio_chip.  That's actually a good example

of why folk like the one-value-per-attribute model with sysfs, at

least for information that would be used with scripting.
- Dave
--

Righteo, so if the kernel explicitly gpio_export()s something, it won't

be gpio_request()ed allowing multiple "owners" making driver debugging

easier.  Most of the time though we don't want to be able to clobber the

kernel's gpios so the control file wizardry isn't so much to cope with

incomplete board support, rather it's the way all regular (ie

non-driver-debugging) gpio access is started..?  Or do you class any

situation where userspace needs primary gpio control as a BSP omission

as there Should Be a formal in-kernel driver for it all?
Also, gpio number discovery can be done through the debugfs interface

already in gpiolib but once you've got a userspace gpio interface which

relies on gpio numbering like this that information ceases to be simple

debugging and becomes pretty mission-critical.  IMO it would make more

sense to shuffle it in to /sys/class/gpio with all this stuff or at
Which is good for simplicity but makes async notification kinda tricky.

I would suggest that a lack of pin-change signalling is going to be a

problem for people who've become accustomed to having it in their

out-of-tree interfaces.  Probably not a showstopper here but certainly
[had some comments regarding the code but it seems akpm covered them all

already :-)]

--

The gpio_export() call requires someone (the caller!) to

have requested the GPIO already.  The "one owner" rule is
Right.  Not unless we're debugging the driver managing
Well, I wouldn't call that "regular"!  But then, I don't

have this "use GPIOs from userspace" focus.  To me, that's
I suppose I'd prefer to see a formal gpio_export() call from

the kernel as part of the BSP, if that's the model for how that

particular board stack should be used.  But I suspect there will

be differing opinions on that point, especially from folk who

avoid custom kernels for whatever reasons.  (Like, "that binary
... intended purely for debugging, not for use with production
I don't follow what you're saying here.  GPIO numbering is deeply

specific to the hardware; so I'd say the relevant hardware docs are

what become mission-critical.  The kernel can't know when some

field update has rewired a bunch of GPIOs, for example...
Trent pointed out that dynamic range assignment can make trouble,

so I can see some help might be needed here.  Were you suggesting

something like a /sys/class/gpio/chips file with contents like
	0-15	gpio

	16-31	gpio

	32-47	gpio

	48-63	gpio

	192-207	mpuio

	208-213	tps65010
Sysfs attributes are supposed to be pollable.  I've not done it,
We accept patches.   Even patches on top of patches.  ;)
- Dave
--

Owner's probably the wrong word.  I was just confirming that in that

case the request/export caller and userspace can both fiddle with the

pin.  Though of course the caller should expect this and behave
Ah well we're backwards there, though now I think of it I can't think of

a great many valid use-cases on my side.  Just for funzies I'll post on

the avrfreaks AVR32 support forum and see how many I can actually dig
Keeping track of which pins aren't used for peripherals then requesting

and exporting them is going to be a pain even for smaller SoCs.  But as

you say, the BSP designer can just opt out if they can't be bothered.
Actually, in, eg AVR32 at32ap we'd have to keep track of all this anyway

so we can call at32_select_gpio() and make the pins ready for pio access
Yeah that's the kind of a thing.  Would be well worth having that info
I'll wait for a final(ish) version and a spare millisecond and see what

might be done :-)
--

Use cases would always help clarify things.  I've seen just

enough to make me understand this is a useful feature, and

for more reasons than just "feature equality" letting us

obsolete three drivers/i2c/chips/*.c drivers and help vanish

half a dozen (at least!) out-of-tree drivers doing that.
The Gumstix user forums and wiki may help too.  ISTR they

have such a GPIO widget (maybe that's the one I saw which

supports polling?) and have shipped it for ages ... so they
I'd have no problem with that.  Some people surely would though;

it has more than one value in that file!  OMG, it's readable! We

can't have any of that!!  The Earth will turn in its grave!  And
OK.  In that case, I think I should plan to rename the "direction"

attribute as "configuration" or something a bit broader ... so that

writing "irq" (or maybe "rising", "falling", "bothedges", "poll")

would eventually configure it as an input with an IRQ handler.
Whenever someone contributes such an async notification scheme,

that is.  ;)
- Dave

--

If you want use cases, how about mine?  I didn't write the code originally for

fun, I wrote it for a real product.
We have a flash chip with a hardware write protected boot block controlled by

a gpio.  If we want to flash this block, we need a way to change the gpio.

patching the mtd driver to do this automatically would require maintaining an

out-of-tree patch, I like to avoid those.  We'd also rather mtd didn't

automatically un-write-protect the boot block; kinda defeats the purpose.
The device may have a daughtercard installed in it.  There is a gpio used as a

presence detect.  We want to be able, from userspace (any maybe kernel too),

to print out "card installed" or "no card installed".  There is also certain

stuff that should run if the card is present when the machine boots.
We have some PCA9557 I2C gpio expanders that encode a device version number.

We want to print this number out in userspace (e.g.  show it in the web

interface, various other application specific interfaces, etc.).  Maybe the

kernel will need to know too, we'll see what happens when there is a version

two.  The daughter card also has a PCA9557 expander, but of course it might
Suppose I want line 5 from the mpuio gpios?  I'd make it so this was:

/sys/class/gpio/mpuio:5
How would you get the sysfs location, with an automatic shell script running
Why not have an irq file for that?

--

Good examples.  Note that the "daughtercard installed" cases generalize

somewhat ... it's not uncommon to do like DRAM sticks do with SPD EEPROMS,

and have a cheap EEPROM identifying characteristics of that card, since

different cards need different initialization/setup.
However, I think a slightly more common practice in current embedded

Linux systems is to build custom kernels that know which daughtercard(s)

are available.  That's mostly what gets pushed upstream, anyway...
ISTR that Gumstix distro kernels use a more retro scheme to identify what's

in the card stack:  they poke at various peripheral addresses to see if the

device on a given card is there.  In the PC space, that's what "ISA Legacy

Drivers" do, albeit at the level of individual peripherals, not cards.
- Dave
--

Oh yeah, nearly every vendor of small not-a-simple-PC Linux boards would

have their own solution to this problem.  About time they were put to
At a glance there's a bunch of how-to but very little why-to.  Bugger.

In fact their driver looks to be mostly obsoleted by gpio-keys anyway so

not only can't a see a specific use-case of their driver, I can't see
xD
Good plan, unless you'd prefer to see "direction" and "interrupt" config

separate.  I have no real preference but IMO

echo "falling" > interrupt

makes more immediate sense than
;)
--

OK, I'll leave it be then.  Given that not all GPIOs support

interrupts, I used the "poll" example intentionally ... being
--

Putting includes inside ifdefs tends to increase the risk of compilation
What prevents FLAG_EXPORT from getting cleared just after we tested it?
urgh.
If we had a strcmp() variant which treats a \n in the first arg as a \0

the above would become
	if (sysfs_streq(buf, "high"))

		status = gpio_direction_output(gpio, 1);

	else if (sysfs_streq(buf, "out") || sysfs_streq(buf, "low"))

		status = gpio_direction_output(gpio, 0);

	else if (sysfs_streq(buf, "in"))

		status = gpio_direction_input(gpio);
urgh.  We cast away the const and then smash up the caller's const string
The string handling in here seems way over-engineered.  All we're doing is

parting "export 42" or "unexport 42".  Surely it can be done better than

this.
The more sysfs-friendly way would be to create separate sysfs files for the
Can we find a way to make HAVE_GPIO_SYSFS go away?  Just use
Then this can just be moved into a #else.

--

Having seen ibm acpi interface... yes, that rule should be aplied for

writes, too.
What about mkdir gpio-N to export it?
--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

The latest version of this patch, which I'll post soonish,

follows the suggestion to have one file for the "export"
Ugh.  That would create way more complication than I want

to see here.  I thought about that early on, and decided

that was Not The Way To Go.
- Dave
--

...but it would be consistent with configfs... and face it... doing

echo > file to make a directory is seriously ugly.

								Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

This isn't configfs, and I didn't happen to notice any polite

way for sysfs users to intercept "mkdir", parse the relevant

directory name, reject illegal names, and pre-populate the

just-created directory with relevant contents.
Were you implying it should go into configfs?  If so, do you

maybe have an update to the patch I sent a day or so ago?
--

No, sorry.
I'm not sure if it should go to configfs, or if sysfs should be

improved. But "something" should be done, because we will be stuck

with this interface for a long while.

									Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

I have a userspace gpio interface which uses /dev and configfs.  The

configfs side was really nice (and used mkdir, as configfs does) but I

wasn't a fan of needing udev..  On balance, I like the all-in-one sysfs

--

This adds a simple sysfs interface for GPIOs.
    /sys/class/gpio

    	/export ... asks the kernel to export a GPIO to userspace

    	/unexport ... to return a GPIO to the kernel

        /gpioN ... for each exported GPIO #N

	    /value ... always readable, writes fail for input GPIOs

	    /direction ... r/w as: in, out (default low); write high, low

	/gpiochipN ... for each gpiochip; #N is its first GPIO

	    /base ... (r/o) same as N

	    /label ... (r/o) descriptive, not necessarily unique

	    /ngpio ... (r/o) number of GPIOs; numbered N .. N+(ngpio - 1)
GPIOs claimed by kernel code may be exported by its owner using a new

gpio_export() call, which should be most useful for driver debugging.

Such exports may optionally be done without a "direction" attribute.
Userspace may ask to take over a GPIO by writing to a sysfs control

file, helping to cope with incomplete board support or other "one-off"

requirements that don't merit full kernel support:
  echo 23 > /sys/class/gpio/export

	... will gpio_request(23, "sysfs") and gpio_export(23);

	use /sys/class/gpio/gpio-23/direction to (re)configure it,

	when that GPIO can be used as both input and output.

  echo 23 > /sys/class/gpio/unexport

	... will gpio_free(23), when it was exported as above
The extra D-space footprint is a few hundred bytes, except for the sysfs

resources associated with each exported GPIO.  The additional I-space

footprint is about two thirds of the current size of gpiolib (!).  Since

no /dev node creation is involved, no "udev" support is needed.
Related changes:
  * This adds a device pointer to "struct gpio_chip".  When GPIO

    providers initialize that, sysfs gpio class devices become

    children of that device instead of being "virtual" devices.
  * The (few) gpio_chip providers which have such a device node

    have been updated.
  * Some gpio_chip drivers also needed to update their module

    "owner" field ... for which missing kerneldoc was added.
  * Some gpio_chips don...
[ message continues ]

ick.  So we got caught partway through constification and we need to

patch it up with a cast.

--

That *is* one value:  a single command, to execute atomically!  :)
ISTR seeing that done elsewhere, and have seen various proposals

that rely on that working.  In any case, the one-per-file rationale
Next version.  If the "is this interface OK" part of the RFC flies,
Good point, I'll move such stuff out of #ifdefs.  I almost
Yeah, the isue there is that the attribute files may

still be open after the GPIO has been unexported.  For

this specific method the existing spinlock can solve

that problem ... but not in general.
Seems like a general fix for that should involve a mutex

covering all those sysfs actions:  read, write, export,

and unexport.  The unexport logic would need reworking,

but the rest could work pretty much as they do now (but

while holding that lock, which would protect that flag).
But that wouldn't change the user experience; the sysfs
That would indeed be better.  Maybe I should whip up a sysfs

patch adding that, and have this depend on that patch.  (I've

CC'd Greg in case he has comments on that...)
Yes.  But as with quite a lot of "rmmod" type paths, there's
Yeah, kind of ugly.  Not particularly happy with that, but

I wasn't keen on allocating a temporary copy of that string
So it does.  That was leftover from a version with

a more complex control interface.  Easy to remove
Or just use negative numbers to mean "unexport";

ugly and hackish, but functional.
I don't want to see the components of one command

split into separate files, where they could be
I'll just make it #ifndef CONFIG_GPIO_SYSFS ... that will make the

interface impossible to provide without gpiolib, but I'm not much

concerned about that.
Note that putting it *here* covers the case of platforms that provide

standard GPIO interfaces but don't use the newish gpiolib code to do

that ... which is why putting it in an #else (above) didn't suffice.
--

Yes, it would be a standalone patch.  The sort which generates oceans of

useful feedback ;) The sort which also generates hundreds of
Yeah, I couldn't think of a decent name.  I do think it should return true

on finding a match so callers don't need to use !  or ==0.  So its name

shouldn't look anything like "strcmp".
--

Heh, sounds good to me :)
Becides, with linux-next, that merge mess is my problem now, not -mm...
thanks,
greg k-h

--

Hard to say where should live, but lib/strings.c seemed fair.

See the appended patch.  I made it not care which string has

newline termination, since caring seems very error-prone.
- Dave
========= CUT HERE

Add a new sysfs_streq() string comparison function, which ignores

the trailing newlines found in sysfs inputs.  By example:
	sysfs_streq("a", "b")	==> false

	sysfs_streq("a", "a")	==> true

	sysfs_streq("a", "a\n")	==> true

	sysfs_streq("a\n", "a")	==> true
This is intended to simplify parsing of sysfs inputs, letting them

avoid the need to manually strip off newlines from inputs.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

---

 include/linux/string.h |    2 ++

 lib/string.c           |   27 +++++++++++++++++++++++++++

 2 files changed, 29 insertions(+)
--- g26.orig/include/linux/string.h	2008-04-29 05:45:53.000000000 -0700

+++ g26/include/linux/string.h	2008-04-29 05:55:14.000000000 -0700

@@ -109,5 +109,7 @@ extern void *kmemdup(const void *src, si

 extern char **argv_split(gfp_t gfp, const char *str, int *argcp);

 extern void argv_free(char **argv);
+extern bool sysfs_streq(const char *s1, const char *s2);

+

 #endif

 #endif /* _LINUX_STRING_H_ */

--- g26.orig/lib/string.c	2008-04-29 05:15:52.000000000 -0700

+++ g26/lib/string.c	2008-04-29 05:55:32.000000000 -0700

@@ -493,6 +493,33 @@ char *strsep(char **s, const char *ct)

 EXPORT_SYMBOL(strsep);

 #endif
+/**

+ * sysfs_streq - return true if strings are equal, modulo trailing newline

+ * @s1: one string

+ * @s2: another string

+ *

+ * This routine returns true iff two strings are equal, treating both

+ * NUL and newline-then-NUL as equivalent string terminations.  It's

+ * geared for use with sysfs input strings, which generally terminate

+ * with newlines but are compared against values without newlines.

+ */

+bool sysfs_streq(const char *s1, const char *s2)

+{

+	while (*s1 && *s1 == *s2) {

+		s1++;

+		s2++;

+	}

+

+	if (*s1 == *s2)

+		return tru...
[ message continues ]

On Tue, 29 Apr 2008 11:45:13 -0700
And
	sysfs_streq("a\n", "a\n") ==> true
Looks good to me.  I'll plan on sliding it into 2.6.26 a few days

hence.
--