Re: [RFC PATCH] gpiolib: Provide and export gpiod_export_name

From: Guenter Roeck
Date: Fri Aug 29 2014 - 01:54:48 EST

On 08/28/2014 10:44 PM, Linus Walleij wrote:
On Mon, Aug 11, 2014 at 5:20 PM, Alexandre Courbot <gnurou@xxxxxxxxx> wrote:
On Tue, Aug 12, 2014 at 12:15 AM, Guenter Roeck <linux@xxxxxxxxxxxx> wrote:

This is just one of many patches which would make it possible to submit
the rest, which would make use of it. What you are saying is that it won't
make sense to submit that series into the kernel, because one of the very
first patches needed to enable that won't be accepted. Kind of a circular
argument, but I guess I'll have to live with it.

Well I have not seen the other patches you mention and cannot guess
their existence. If you send the full series it will of course be
considered as such, but right now this lone patch does not hint any
upstream user for this interface.

Note that this doesn't change anything to the core of the argument ;
we have not heard what Linus thinks about named GPIOs in
/sys/class/gpio yet, maybe he will have a different opinion...

The sysfs is sort of broken by design because of things like this and
some other stuff.

I think the sysfs is scary, for example since it's not hierarchical
but flat and build on the assumption that there is one single
GPIO numberspace. As pointed out in some other message
in the thread it would be nicer to have:


instead of the horrid sysfs ABI that will have to maintain forever.

Blocking any attempts to make it more useful doesn't help much, though.

Still it is true that there is a precedent for named GPIOs in sysfs.

And in the end, userspace needs a way to figure out how to
get what it needs, a unique string is as good as anything.
I would be feeling better if userspace got that name from an
ioctl() on some /dev/* node than by plain filename search in
sysfs. I somewhat feel a named gpio in sysfs is more
helpful than just "gpio25".

That was the point. The code necessary to find out that a specific
function on a specific board is tied to gpiochip X pin Y is quite
complex. It seemed to be much easier to be able to rely on a well
defined pin name.

The argument of "there can be duplicate names" is, in my opinion,
quite bogus. Sure, there can be duplicate names. That is why one
has error codes. With such an argument you can block anything
you want.

Regarding ioctls, I thought sysfs was supposed to replace ioctls,
and that adding new ioctls was discouraged. Are we reverting on that ?

But I'm not happy about merging the patch if Alexandre is

Guess that's life. I'll just have to live with it.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at