linux-kernel - Re: [RFC/PATCH] arch-neutral GPIO calls: AVR32 implementation

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:	Mon, 20 Nov 2006 21:06:58 -0800
From:	David Brownell <david-b@...bell.net>
To:	Bill Gatliff <bgat@...lgatliff.com>
Cc:	Haavard Skinnemoen <hskinnemoen@...el.com>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>,
	Andrew Victor <andrew@...people.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: [RFC/PATCH] arch-neutral GPIO calls: AVR32 implementation

On Monday 20 November 2006 7:11 pm, Bill Gatliff wrote:
> 
> In fact, at least at first glance there's really no need for a static 
> array at all on many chips that I can think of.  At most, the 
> gpio_request() function should build up a temporary bitmask using 
> information read from the hardware, then discard that temporary bitmask 
> after the request is completed and the hardware actually configured.

Let's go back to what gpio_request() is defined to do, though:  it very
explicitly "does NOT cause it to be configured in any way", and succeeds
unless the specified GPIO has "already been claimed".


It's addressing problems related only to software configuration:

> + These APIs serve two basic purposes.  One is marking the signals which
> + are actually in use as GPIOs, for better diagnostics; systems may have
> + several hundred potential GPIOs, but often only a dozen are used on any
> + given board.  Another is to catch confusion between drivers, reporting
> + errors when drivers wrongly think they have exclusive use of that signal.

Example, it's a bug if two drivers both thinking they manage GPIO 17.


> >No, but letting the second one report the fatal error is a big help.
> >And heck, you've got reasonable chance the first driver will work,
> >if the second doesn't interfere with it!  (Or maybe it's the other
> >way around.  At least you'd have logged a fatal error message ...)
> >  
> >
> 
> If the gpio_request() is reading from the hardware,

... which it must not do ...

> it could determine  
> that a GPIO line was assigned to a peripheral function by the 
> bootloader; 

On AT91, and AVR32, yes ... since those GPIO controllers are also
involved in pin muxing, and they use a very simple mux model.
(And if the pin were assigned as a GPIO, or not ... so what?  That
doesn't mean that's how Linux must use it.)

But in general, no ... the general case is that GPIO controller(s)
and pin muxing are two separate units in the silicon, and there's
no one-to-one coupling possible.


> >Admittedly, the GPIO controller in those Atmel chips (AVR32,
> >AT91) does have a one-to-one mapping for muxable pins and GPIOs,
> >but that's not a portable notion.
> >  
> >
> 
> Can you refer me to a specific chip that is contrary to the AVR32/AT91 
> notion, so that I can be sure I'm understanding what you're saying?

See my previous email, which gives detailed and very specific examples
with respect to OMAP 5912 chips you get overnight from e.g. Digikey,
and where the pin-to-gpio mapping space is many-to-many.

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