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
| ||
|
Date: Wed, 27 Dec 2006 17:49:54 +0000 From: Pavel Machek <pavel@....cz> 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>, pHilipp Zabel <philipp.zabel@...il.com> Subject: Re: [patch 2.6.20-rc1 1/6] GPIO core Hi! > +Identifying GPIOs > +----------------- > +GPIOs are identified by unsigned integers in the range 0..MAX_INT. That > +reserves "negative" numbers for other purposes like marking signals as > +"not available on this board", or indicating faults. > + > +Platforms define how they use those integers, and usually #define symbols > +for the GPIO lines so that board-specific setup code directly corresponds > +to the relevant schematics. In contrast, drivers should only use GPIO Perhaps these should not be integers, then? typedef struct { int mydata } pin_t; prevents people from looking inside, allows you to typecheck, and allows expansion in (unlikely) case where more than int is needed? ...hotpluggable gpio pins? > +Spinlock-Safe GPIO access > +------------------------- > +Most GPIO controllers can be accessed with memory read/write instructions. > +That doesn't need to sleep, and can safely be done from inside IRQ handlers. > + > +Use these calls to access such GPIOs: > + > + /* GPIO INPUT: return zero or nonzero */ > + int gpio_get_value(unsigned gpio); > + > + /* GPIO OUTPUT */ > + void gpio_set_value(unsigned gpio, int value); > + > +The values are boolean, zero for low, nonzero for high. When reading the > +value of an output pin, the value returned should be what's seen on the > +pin ... that won't always match the specified output value, because of > +issues including wire-OR and output latencies. > + > +The get/set calls have no error returns because "invalid GPIO" should have > +been reported earlier in gpio_set_direction(). However, note that not all > +platforms can read the value of output pins; those that can't should always > +return zero. > Also, these calls will be ignored for GPIOs that can't safely > +be accessed wihtout sleeping (see below). 'Silently ignored' is ugly. BUG() would be okay there. > +Platforms that support this type of GPIO distinguish them from other GPIOs > +by returning nonzero from this call: > + > + int gpio_cansleep(unsigned gpio); This is ugly :-(. But I don't see easy way around... > +GPIOs mapped to IRQs > +-------------------- > +GPIO numbers are unsigned integers; so are IRQ numbers. These make up > +two logically distinct namespaces (GPIO 0 need not use IRQ 0). You can > +map between them using calls like: > + > + /* map GPIO numbers to IRQ numbers */ > + int gpio_to_irq(unsigned gpio); > + > + /* map IRQ numbers to GPIO numbers */ > + int irq_to_gpio(unsigned irq); . Don't we have irq_t already? > +Those return either the corresponding number in the other namespace, or > +else a negative errno code if the mapping can't be done. (For example, > +some GPIOs can't used as IRQs.) It is an unchecked error to use a GPIO > +number that hasn't been marked as an input using gpio_set_direction(), or It should be valid to do irqs on outputs, if those outputs are really tristates (wire-or or how you call it?)? Pavel -- Thanks for all the (sleeping) penguins. - 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/
Powered by blists - more mailing lists