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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200611202135.39970.david-b@pacbell.net>
Date:	Mon, 20 Nov 2006 21:35:38 -0800
From:	David Brownell <david-b@...bell.net>
To:	Bill Gatliff <bgat@...lgatliff.com>
Cc:	Paul Mundt <lethal@...ux-sh.org>,
	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 Monday 20 November 2006 9:09 pm, Bill Gatliff wrote:
> Why not have GPIO numbers refer to unique combinations of GPIO+pin? 

That sounds unduly complicated compared to just using the GPIO numbers
which are used throughout the hardware and software docs.  It'd also
be a big (and needless) disruption to code that's been working fine for
several years now ... and there'd need to be some scheme to recognize
that most GPIO numbers suddenly become invalid (since the space would
become large and sparsely populated, vs small and dense).

Maybe if it were being done over from scratch, that'd be workable.
But at this point I have a hard time seeing anyone want to change,
even if there were a better argument.

> If the GPIO line is tied to a piece of external hardware, that connection 
> is surely through a specific pin.  So it seems like you'd need GPIO+pin 
> every time there was an option.

Pin muxing is set up once, early, and from then on it suffices to use
the GPIO number.  The mux problems are orthogonal to GPIOs.

> 	It seems like the point 
> here is to help a driver find and assert their GPIO _pin_ so that the 
> driver can can talk to the attached external hardware.

Updating the GPIO controller is always (all architectures!) done in terms
of a number mapping to some controller and a bit number, not a pin.  The
drivers never care about pins.

The only thing that cares about pins is board setup code -- briefly.

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