linux-kernel - Re: Suggestion on GPIO sysfs interface (gpio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4d34a0a70904211909o430a4db3t61b7997a4124c3a1@mail.gmail.com>
Date:	Wed, 22 Apr 2009 11:09:27 +0900
From:	Kim Kyuwon <chammoru@...il.com>
To:	David Brownell <david-b@...bell.net>
Cc:	Kim Kyuwon <q1.kim@...sung.com>,
	LKML <linux-kernel@...r.kernel.org>, kyungmin.park@...sung.com,
	민병호 <bhmin@...sung.com>
Subject: Re: Suggestion on GPIO sysfs interface (gpio_export)

On Tue, Apr 21, 2009 at 1:52 AM, David Brownell <david-b@...bell.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/