[PATCH] [MTD] [NAND] GPIO NAND flash driver

[David Brownell]

> +#ifdef CONFIG_ARM
> +/* gpio_nand_dosync()
> + *
> + * needed due to bus-reordering within the PXA itself (see section on
> + * I/O ordering in PXA manual (section 2.3, p35)
> + */
> +static void gpio_nand_dosync(struct gpiomtd *gpiomtd)

I'm trying to understand why a PXA-specific issue is getting
applied to all ARMs.  #ifdef CONFIG_ARCH_PXA would be better
for *any* PXA-specific behavior like this.


Reading the list archives, I also see some confusion about
GPIO state after gpio_free() is called.  As soon as a GPIO
is no longer managed (as a GPIO) by a driver, it's fair for
the rest of the system to reconfigure it ... but platform
specific issues like "Will *this* system reconfigure it?
If so, how? and When?" are out-of-scope.  (Just like all
aspects of configuring pins for GPIO v. non-GPIO usage...)

The principle-of-least-surprise applies here, as it should
apply everywhere, though ... so until something takes over
the pin(s) used for that GPIO and reconfigures it (them) for
another purpose, it's reasonable to expect no state changes.
And it's likewise reasonable to expect that any kernel code
taking it over isn't fundamentally brain-dead ...

One general rule being that if you care what the hardware
is doing, you should have its driver managing that:  don't
unload the darn driver, if unloading it may break things!


That's not quite the same as the confusion about state at
low power levels.  In that case, drivers are within their
rights to claim that if platform code changes GPIO state
except according to driver requests, the platform is buggy.

(That includes the special configuration requests that can
be made on some platforms, covering low power modes.  I've
seen that on a couple systems, but it's currently rare and
thus very appropriate to treat as platform-specific.)

- Dave

p.s. In current kernel GIT there are two new hooks in
     the gpiolib framework, called on gpio_request()
     and gpio_free().  The intent is to support power
     management ... e.g. save 50uA by keeping unused
     GPIO banks unclocked or even powered off when not
     in use.  Such hooks are unfortunately open to some
     abuse ... I suspect platform-specific stupidities
     will start to appear.  Not much I can do about it.