linux-kernel - Re: [PATCH v2] cs5535-gpio: change input/output enable to match gpiolib expectations

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:	Sat, 27 Feb 2010 11:18:51 -0800
From:	David Brownell <david-b@...bell.net>
To:	Ben Gardner <gardner.ben@...il.com>
Cc:	linux-kernel@...r.kernel.org,
	Andres Salomon <dilinger@...labora.co.uk>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jani Nikula <ext-jani.1.nikula@...ia.com>
Subject: Re: [PATCH v2] cs5535-gpio: change input/output enable to match gpiolib expectations

On Saturday 27 February 2010, Ben Gardner wrote:

Patch seems OK, but the comment could stand correction:

> The intent of the gpiolib set_direction_xxx functions is as follows:

Clarification:  it's not "gpiolib" which expects that; "gpiolib"
is just an optional implementation infrastructure for the GPIO
programming interface.

That behavior is better described as a "weak expectation" than an
intent.  It comes from the GPIO programming interface, as described
in Documentation/gpio.txt ...

And the reason it describes that weak expectation is that it's how
most GPIO hardware behaves ... in particular, how the GPIO banks of
most System-on-Chip (SoC) processors behave.  (Even on boards with
external GPIO controllers, the SoC GPIOs generally outnumber the
external GPIOs by one or more orders of magnitude.)

Since the behavior of reading an "output" GPIO's value needs to
be specified ... this issue comes up.

> output: enable both input and output
> input: disable output, enable input

... the expectation is "weak" in that output-only is very
much allowed.  However, if a gpio is going to provide that
model, (a) it needs to report its value as 0/low/false when
asked, which (b) may well trigger some odd behavior in
some other driver code that expects more typical behavior

(You *could* also return 0/low/false for output-only GPIOs.
But this behavior is more typical, and much more useful.)

So a better explanation of this patch would emphasize that
it's providing "more typical behavior" to reduce surprises.

- 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/