Re: [patch 2.6.24-rc2 1/3] generic gpio -- gpio_chip support

[David Brownell <david-b@pacbell.net>]

On Thursday 15 November 2007, Haavard Skinnemoen wrote:
> On Thu, 15 Nov 2007 00:20:33 -0800
> David Brownell <david-b@pacbell.net> wrote:
> 
> > > >   - gpio_direction_input()/gpio_direction_output() implicitly
> > > >     request the pins, if they weren't already requested.  
> > > 
> > > Eek, that's completely wrong. Allowing to access a resource _before_
> > > it is assigned and then doing the assignment implicit is a really bad
> > > idea.  
> > 
> > This is an artifact of making the GPIO interface easy to adopt,
> > by letting all the initial adopters wrap "legacy" SOC-specific
> > GPIO interfaces instead of creating a bunch of new platform code.
> 
> It's still ok for platforms that do not use gpiolib to provide NOP
> gpio_request() and gpio_free() functions if they don't care about
> tracking gpio usage.

In fact they *must* provide some implementation of those calls,
and several platforms do exactly that.  (Since the legacy GPIO
code didn't use such primitives ... nothing to wrap.)


> That doesn't mean we shouldn't require all drivers 
> to use those calls -- if they are implemented as empty inlines, it
> won't cost anything to call them.

Thing is, issuing those calls is not currently mandatory ... so
requiring use of them would be an incompatible API change, which
would require auditing (and fixing, and testing) much platform code.


> I'd rather speed up the gpio_direction_* functions a bit by removing
> the implicit gpio_request() since they may be called a lot more
> frequently and, as you pointed out, possibly from atomic context.

In fact, possibly before IRQs get set up ... some platforms start
using GPIOs very early in system setup.

- Dave