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

[Russell King - ARM Linux]

On Sun, Oct 12, 2008 at 03:22:45PM -0400, Mike Frysinger wrote:
> On Sun, Oct 12, 2008 at 15:09, Russell King - ARM Linux wrote:
> > On Sun, Oct 12, 2008 at 03:04:06PM -0400, Mike Frysinger wrote:
> >> On Sun, Oct 12, 2008 at 06:13, Russell King - ARM Linux wrote:
> >> > It doesn't.  The fact that the GPIO state is preserved when free'd on
> >> > PXA is just that it takes _more_ code to do anything else.
> >>
> >> so which is it ?  GPIO state *should* be preserved, or PXA does it
> >> simply due to code frugality ?
> >
> > May I remind you that _you_ are the one with the system which doesn't
> > preserve GPIO state.
> >
> >> if the API behavior is strictly documented, your complaint here is
> >> pretty moot.
> >
> > My complaint?  I don't have a complaint.  You are the one with the
> > complaint with the driver that's being discussed.  You're the one
> > who's moaning about it setting state before calling gpio_free.
> >
> > I see no point in continuing this discussion; your arguments are
> > just plain silly.  I've explained _why_ we're doing it.
> >
> > Our GPIO hardware behaves differently from yours.  Our gpio_free()
> > is side-effect free.  Get over it.
> 
> i'm attempting to get things fixed for everyone.  stop being so
> abrasive over nothing.

Me being abrasive?  ROTFL.  You're the one being difficult and constantly
twisting what I'm saying.

> my question is simply:
> > if certain behavior is expected, then it should be codified.  i see no
> > mention (unless i just missed it) of expected behavior upon freeing in
> > Documentation/gpio.txt.
> 
> and i havent gotten a straight answer out of you about this.  should
> state be retained when a pin gets freed or not ?

How the hell do I know?  Ask the GPIO library authors what *their*
intention of their interface is!

Look, so you can be clear for my point:

1. GPIO hardware state may be unaffected by gpio_free() - since it's
   undefined whether gpio_free() has any side effects.
2. Real implementations today exist where gpio_free() does not affect
   hardware state.
3. NAND may be connected to GPIOs for the control signals.
4. For hardware where gpio_free() does not affect hardware state, it
   makes total sense to ensure that GPIOs are set to inactive states
   prior to free.

That is the basis of my point.  Not "don't need pull ups".  And not
anything else that you're busy trying to twist my damned words into.

I don't care whether pull ups exist - because that's completely
irrelevent in the case where hardware state is unaffected by gpio_free.
You're the one bringing the issue of pull ups into this discussion,
not me.  You're the one clouding the issue.

Let me repeat.

1. gpio_free() is undefined wrt hardware side effects.
2. Some implementations may preserve the existing state, others may not.
3. To cater for all, setting the hardware state to inactive is _clearly_
   the right thing to do.

So, stop twisting my bloody words into your own stupid arguments.

I'm done with this thread.