Re: [PATCH v5 1/4] gpiolib: Add "unknown" direction support

From: Peter Tyser
Date: Sun Mar 06 2011 - 21:44:12 EST


> The thing about gpios is that how they are used is entirely dependant
> on what they are wired up to. There is no avoiding the fact that you
> *absolutely* must understand the usage model before even considering
> fiddling with a gpio (ignoring the "I wonder what this knob does"
> use-case such as when reverse engineer a board). So, while it is nice
> to have an 'unknown' state for sysfs to report, it is certainly not
> required. The model still remains that the pin direction must be set
> before (or at the same time as) reading/writing the pin.

As is, even if someone knows about the GPIO wiring on their board, they
have to know Linux has a "rule" that "before I can use a GPIO, I have to
explicitly set its direction, even if the current reported direction is
what I want". A number of our customers have tried to use a GPIO which
states its an 'input' as an input after exporting it, which is
completely logical. But it doesn't work, because its not really an
input... Why not set the direction accurately as 'unknown' so users
intuitively know they have to set the direction before using it? You
also mention that it would be a nice feature above, so why not include
it?

> Since the addition of an 'unknown'
> direction is solely for benefit of the sysfs interface, I don't (yet)
> see a valid argument for adding it. *Who cares* if sysfs might report
> direction as 'input' inaccurately? It may be mildly inconvenient to a
> human reader, but it doesn't change the usage model one iota because
> the direction still must be explicitly set before using the gpio.

Adding an 'unknown' direction *forces* people to use the recommended
usage model. As is, I'd guess most end users don't know about the
recommended usage model, and they are misled by the incorrect info in
sysfs to boot.

Best,
Peter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/