Messages in this thread | | | From | David Brownell <> | Subject | Re: Suggestion on GPIO sysfs interface (gpio_export) | Date | Mon, 20 Apr 2009 09:52:34 -0700 |
| |
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 -- 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/
| |