linux-kernel - Re: [PATCH 1/3] gpiolib: add gpio_set

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:	Fri, 26 Feb 2010 23:02:18 -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>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jani Nikula <ext-jani.1.nikula@...ia.com>
Subject: Re: [PATCH 1/3] gpiolib: add gpio_set_direction()

On Friday 26 February 2010, Ben Gardner wrote:
> Combine gpio_direction_input() and gpio_direction_output() into
> gpio_set_direction().

NAK. 

When we discussed the programming interface originally, having the
direction be part of the function name was explicitly requested as
a way to reduce programming errors.

I recall that  a gpio_set_direction() was in the original proposal...
removing that was one of the handful of fixes that went into the final
set of calls in this programming interface.

And in fact  ... it *was* very easy to make errors with a few GPIO
interfaces which worked like that.  With even fewer parameters to
create confusion than in your proposal.

Let's have no retrograde motion...


> Add 'none' and 'inout' directions to the sysfs interface.

Both of those seem nonsensical:

 "none" ... since it's not even a GPIO, why would it show
	up through the GPIO subsystem???

 "inout" ... is not a direction.  But if you want to do this,
	you really ought to bite the bullet and come up with a
	way the implementation can pass up its capabilities.

	Did you read the definition of gpio_get_value()?  It says
	"When reading the value of an output pin, the value returned
	should be what's seen on the pin ... that won't always match
	the specified output value, because of issues including
	open-drain signaling and output latencies."  Also:  "note that
	not all platforms can read the value of output pins; those that
	can't should always return zero."

	Another way to say that is that "output" means 'inout" except
	when the platform can't do that.  So you'd need to address the
	case of hardware that's truly output-only ... instead of
	ignoring that, as done here.  (That is:  you'd need to have a
	way to reject "inout" mode ... or for that matter, "output-only".)


	Doing that well might be a Good Thing ... if for example it
	lets the initial mode of a GPIO show up properly ... there's
	currently an assumption in sysfs that they start up as "input",
	which of course makes sense for any power-sensitive system
	(you don't enable output drivers unless that power consumption
	is for some reason required).

	I've never, for example, seen GPIO hardware that would support
	the equivalent of that "open in <bitmask> mode".   It's either
	unidirectional (rarely), or (normally) the only real option is
	whether the output drivers are disabled.  So you always get the
	"inout" semantics described above, or input-only ones.  Asking
	for output-only would need to fail.  (Or in the less typical
	cases, it's asking for "inout" that would need to fail.)

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