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: <20061113183811.GA19979@linux-sh.org>
Date:	Tue, 14 Nov 2006 03:38:11 +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>, 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 13, 2006 at 12:19:11PM -0600, Bill Gatliff wrote:
> True, but right now if the "multiple GPIO controllers" are on something 
> like i2c/spi, they have the synch/asynch issues that Jamey mentioned and 
> so are by definition out of scope for this proposal.  If the GPIO lines 
> are in an MMIO controller (PLD/FPGA, perhaps), then there's no reason 
> that the board implementer couldn't address that in their implementation 
> of the proposed functions.
> 
They're something that has to be accounted for in any sort of API, or we
just end up throwing it all out and starting over again. I was thinking
more of the SuperIO or mfd device scope, where this _is_ a requirement.

> ... except that I bet David is thinking that the implementations will be 
> in arch/arm/irq-at91rm9200.c or something, and not in 
> asm/arm/board-xyz.c, so it's the arch implementer's responsibility and 
> not the platform author's.  Yea, I see your point now.
> 
The problem with this is that it gets in to something that's getting
close to static pin state configuration. Setting up the mux from platform
code is brain-damage, since it's ultimately up to the system and driver
inserted at the time to grab and configure the pin as necessary, the
board or CPU code is not going to have any notion of the "preferred" pin
state, especially in the heavily muxed case.

> I say that we go with David's proposal for 2.6.19 anyway, and maybe by 
> 2.6.20 we'll have a consensus on how to address that with some 
> behind-the-API magic.  :)  (functions added to the machine descriptor, 
> maybe?)
> 
This is all too late for 2.6.19 regardless. We've gone this long without
a generic API, I see no reason to merge a temporary hack now if it's not
going to be satisfactory for people and require us to throw it all out
and start over again anyways.

I have a real need for supporting multiple controllers and handling
muxing dynamically from various drivers on various architectures, and
anything that exposes the pin # higher than the controller mapping to
function level is never going to work. Drivers have _zero_ interest in
pin #, only in the desired function.
-
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/