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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 20 Apr 2009 09:52:34 -0700
From:	David Brownell <david-b@...bell.net>
To:	Kim Kyuwon <q1.kim@...sung.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Guennadi Liakhovetski <g.liakhovetski@...gutronix.de>,
	Greg KH <greg@...ah.com>, Kay Sievers <kay.sievers@...y.org>,
	kyungmin.park@...sung.com, chammoru@...il.com
Subject: Re: Suggestion on GPIO sysfs interface (gpio_export)

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/