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:	Tue, 14 Nov 2006 02:38:00 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	David Brownell <david-b@...bell.net>
Cc:	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>,
	Andrew Victor <andrew@...people.com>,
	Bill Gatliff <bgat@...lgatliff.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 Sat, Nov 11, 2006 at 03:41:32PM -0800, David Brownell wrote:
> I know there have been discussions about standardizing GPIOs before,
> but nothing quite "took".  One of the more recent ones was
> 
>   http://marc.theaimsgroup.com/?l=linux-kernel&m=110873454720555&w=2
> 
> Below, find what I think is a useful proposal, trivially implementable on
> many ARMs (at91, omap, pxa, ep93xx, ixp2000, pnx4008, davinci, more) as well
> as the new AVR32.
> 
> Compared to the proposal above, key differences include:
> 
>   - Only intended for use with "real" GPIOs that work from IRQ context;
>     e.g. pins on a SOC that are controlled by chip register access.
> 
>   - Can be trivially implemented today, on many systems (see partial
>     list above) ... no "provider" or gpiochip API necessary.
> 
>   - Provided in the form of a working patch, with sample implementation;
>     known to be viable on multiple architectures and platforms.
> 
>   - Includes Documentation/gpio.txt
> 
> Comments?
> 
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.

Exposing the pin # abstraction any higher than the CPU-specific code
hidden away in an architecture backend is just asking for abuse,
specifically for drivers that are shared across different architectures
(or where the peripheral may only be conditionally hooked to a GPIO or
require demuxing).

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