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: <200611211013.19127.david-b@pacbell.net>
Date:	Tue, 21 Nov 2006 10:13:17 -0800
From:	David Brownell <david-b@...bell.net>
To:	Paul Mundt <lethal@...ux-sh.org>
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 Monday 20 November 2006 10:09 pm, Paul Mundt wrote:
> 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.

Not much.  The only counterexample I know about just now is wanting
to use a UART.RX pin as a wakeup GPIO, even when the baud rate clock
is turned off during sleep ... only on development platforms.

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

Not entirely "mine" ... except in the writeup of the abstraction that's
already in wide use (with different syntax).

If we can agree on syntax, and factoring pin mux separately (however it
gets implemented) I think the immediate goal is satisfied.

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

It's realistic in a couple dozen different systems I've seen, including
ones using OMAP2.  Isn't that serious enough?  :)

> So given that, I would argue that drivers _do_ care about the pins, just
> not through the GPIO API.

I'm not quite sure what you're getting at with that any more, but so long
as you agree that it makes sense to have a GPIO API with more or less the
syntax I collected, distinct from pin mux/setup/reconfig, we're in close
enough agreement to move forward to whatever.

I know some folk say they "need" to remux after boot in non-exceptional cases,
but the ability to do that (or not) really seems like a separate discussion.

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