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]

Date:	Wed, 22 Nov 2006 12:55:17 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Bill Gatliff <bgat@...lgatliff.com>
Cc:	David Brownell <david-b@...bell.net>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>,
	Andrew Victor <andrew@...people.com>,
	Haavard Skinnemoen <hskinnemoen@...el.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 Tue, Nov 21, 2006 at 09:36:17PM -0600, Bill Gatliff wrote:
> David Brownell wrote:
> >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.
> 
> I don't need to REmux, but I don't want to bother setting up the routing 
> manually at all.  I think the GPIO management stuff can do it properly 
> on my behalf, given the information we have to acquire to get the GPIO 
> API to work in the first place.
> 
You can't really have one without the other, and if you're going to add
that sort of functionality, it's not strictly tied to the GPIOs.

> Kind of like with request_irq() and enable_irq().  The driver is saying, 
> "I don't care what's actually behind this interrupt source X, I just 
> want it routed over to me".  If we commit to hiding the muxing behind 
> the API, instead of defining a new, parallel API,  we get that kind of 
> mentality for GPIO as well.
> 
As soon as a driver comes along and says that it wants, say, GPIO 42,
which happens to be an alternate pin function for pin #128, you've
effectively coupled the two, especially since the underlying refcounting
is more applicable to the pin function than the GPIO itself.

And this is something where you will have to remux, or at least force
that GPIOs availability through the board setup code, but there's little
point in dealing with mux issues in the board setup code at all if this
is done dynamically based off of the driver requirements and subsequent
refcounting.

Static muxing is something that no longer makes any sense. Devices are
piling more and more desired functions under mux, and that's not going
away.
-
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/