linux-kernel - Re: [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls

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]

Message-ID: <20061121060918.GA2033@linux-sh.org>
Date:	Tue, 21 Nov 2006 15:09:18 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	David Brownell <david-b@...bell.net>
Cc:	Bill Gatliff <bgat@...lgatliff.com>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>,
	Andrew Victor <andrew@...people.com>,
	Haavard Skinnemoen <hskinnemoen@...el.com>, jamey.hicks@...com,
	Kevin Hilman <khilman@...sta.com>,
	Nicolas Pitre <nico@....org>,
	Russell King <rmk@....linux.org.uk>,
	Tony Lindgren <tony@...mide.com>
Subject: Re: [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls

On Mon, Nov 20, 2006 at 09:35:38PM -0800, David Brownell wrote:
> On Monday 20 November 2006 9:09 pm, Bill Gatliff wrote:
> > 	It seems like the point 
> > here is to help a driver find and assert their GPIO _pin_ so that the 
> > driver can can talk to the attached external hardware.
> 
> Updating the GPIO controller is always (all architectures!) done in terms
> of a number mapping to some controller and a bit number, not a pin.  The
> drivers never care about pins.
> 
> The only thing that cares about pins is board setup code -- briefly.
> 
That's rather simplifying things. The driver using the GPIO number isn't
going to care about the pin number that it's associated with, but that's
not to say that another driver won't have an interest in the alternate
function of the pin that the GPIO is tied to, while the first driver is
expecting it to be used as a GPIO.

There is a need to layer a pin mux API underneath the GPIO API to deal
with these sorts of things, but that's obviously up to the platform to
take care of, and I think your API is a fairly good staging ground for
building up the layering in the platform parts.

Claiming that we set the pins once in the board setup code and then
forget about it is not realistic. I can't imagine anyone with many
different pin functions under mux (OMAP2 does too) seriously taking that
position.

So given that, I would argue that drivers _do_ care about the pins, just
not through the GPIO API.
-
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/