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: <82ecf08e0611130956m9f30bf0t2a7b62307d5f70ca@mail.gmail.com>
Date:	Mon, 13 Nov 2006 13:56:04 -0400
From:	"Thiago Galesi" <thiagogalesi@...il.com>
To:	"Paul Mundt" <lethal@...ux-sh.org>,
	"David Brownell" <david-b@...bell.net>,
	"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

Ok, some ideas:

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

I guess that a kind of "name addressing" would be the way to go, we
need to get to it by "location" (I'm thinking PortA 20, PortB 5 rather
than pin number or some other arbitrary convention; we need a way to
not need to look up what 'Port X pin B' should be called.

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

Seconded

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

Agreed, but maybe 'not now'

Another thing that may be considered is the ability to get 'pointers'
for GPIOs. And, of course, protecting GPIOs from concurrent accesses

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