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]

Message-ID: <45626E7F.8000100@billgatliff.com>
Date:	Mon, 20 Nov 2006 21:11:59 -0600
From:	Bill Gatliff <bgat@...lgatliff.com>
To:	David Brownell <david-b@...bell.net>
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

David Brownell wrote:

>That's different from pin mux setup, which for most embedded
>systems is just making sure the SOC is configured to match
>what Linux expects.  The boot loader usualy does some of that,
>but it's probably not validated to do more than reliably boot
>an operating system ... so pin muxing can't realistically
>report anything as an error.  At best, it's a suggestion to
>update the bootloader someday.
>  
>

The ARM platforms I've worked with provide enough read-only information 
to allow you to report the status/assignment of a GPIO line, be it 
input, output, or assigned to one of several peripheral functions.  So 
you definitely want to read that stuff and report from it rather than 
just the state of a static array somewhere.

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.

>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, it could determine 
that a GPIO line was assigned to a peripheral function by the 
bootloader; then it could refuse that request to the caller.  The fact 
that we don't have an API to assign the pin to a peripheral function 
would be even less of a concern then, because ordinary GPIO users of the 
pin could still avoid accidentally assigning a peripheral function pin 
to themselves as GPIO.

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

b.g.

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