Messages in this thread | | | From | Kim Kyuwon <> | Date | Wed, 22 Apr 2009 11:09:27 +0900 | Subject | Re: Suggestion on GPIO sysfs interface (gpio_export) |
| |
On Tue, Apr 21, 2009 at 1:52 AM, David Brownell <david-b@pacbell.net> wrote: > 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.
Thank you for pointing out problems :)
> 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.
Yes, we have a few devices which can be controlled by only 1 GPIOs. I thought it is too small to make new drivers for these devices. So I just tried to use gpio_export() function. hmm.. I have to make do with new platform drivers for 1-GPIO controlled devices. Anyway, thank you for your tip!
> - Dave >
-- Kyuwon (규원) -- 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/
| |