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: <4558B71F.9020502@billgatliff.com>
Date:	Mon, 13 Nov 2006 12:19:11 -0600
From:	Bill Gatliff <bgat@...lgatliff.com>
To:	Paul Mundt <lethal@...ux-sh.org>
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

Paul:

Paul Mundt wrote:

>I'm not convinced that exposing the pin number to drivers is the way to
>go. The pin numbers themselves are rarely portable across "similar" CPUs
>with identical peripherals, while the pin function itself may be
>portable (or simply unecessary). Pin muxing also needs to be handled in a
>much more transparent and intelligent fashion, which is something else
>that is fairly easy to do when looking at a symbolic name for the pin
>function rather than the pin # itself.
>  
>

I don't think he's exporting pin numbers per se.  It's more like an 
enumeration that comes in from the platform data that the driver passes 
back to the GPIO (and, indirectly, the IRQ) API.

>Any API also needs to allow for multiple GPIO controllers, as it's rarely
>just the CPU that has these or needs to manipulate them.
>  
>

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.

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

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?)

b.g. , who can't post to the lists at the moment because his ISP is 
having a sudden fit of outbound email filter mania.

-- 
Bill Gatliff
bgat@...lgatliff.com

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