lkml.org 
[lkml]   [2009]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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/

\
 
 \ /
  Last update: 2009-04-22 04:13    [W:0.242 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site