Re: Suggestion on GPIO sysfs interface (gpio_export)

[David Brownell <david-b@pacbell.net>]

On Sunday 19 April 2009, Kim Kyuwon wrote:
> Can I ask you opinion about this idea?

First issue:  labels aren't required to be unique, so
there's a certain level of unpredictability you're
introducing.  Exports using this new flag would fail
sometimes depending on what *other* exports did.
(That's part of the reason "gpio%d" names got used
in the first place!)

Another layer of unpredicatability comes from the
way those strings are only available given debugfs.


Second:

> -extern int gpio_export(unsigned gpio, bool direction_may_change);
> +extern int gpio_export(unsigned gpio, bool direction_may_change,
> +                                                       bool label_may_show);

It's generally confusing to add more parameters of the same type
like that; there's no fundamental reason for people to remember
which one means what, and the compiler can't help at all when (!)
they get confused.


Have you thought much about other options?  Like for example
adding a new call.  With each MMC card slot, for one example,
there would often be two GPIOs:  card_detect, write_protect.
With two such slots, the "label" wouldn't be much help unless
it were specifically made unique.

Instead of exporting the GPIOs in a "flat" namespace, maybe
something like

  gpio_export_dev(struct device *dev, const char *tag,
		unsigned gpio, bool direction_may_change);

would be more useful.  It could gpio_export() the standard
way, then set up a symlink using "tag" to set up a symlink
from /sys/.../dev/tag to /sys/class/gpio/gpioN node.  Easy
to see how that would work for those MMC examples.

I can imagine there would be times when the GPIO doesn't
have a logical coupling to any device, of course.  So maybe
that doesn't address your particular issue.

- Dave