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

Mike Frysinger vapier.adi at gmail.com
Sun Oct 12 15:22:45 EDT 2008


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.

your original comments:
> Maybe you should reconsider that behaviour - this is a prime example
> why such behaviour is wrong.
>...
> I'll say that I've never liked this GPIO layer, because it breads ideas
> like you're putting forward, which have traditionally not been needed
> to be thought about when writing direct to the registers - where you
> have system wide control of the GPIO state without any of this "on
> gpio_free() such and such might happen" ideas.

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 ?  you cant say "your
implementation is broken" if you dont say *what* the expected behavior
is and the behavior you claim isnt documented.  what
$random-implementation does is irrelevant.  the agreed upon API is the
only thing that matters.
-mike



More information about the linux-mtd mailing list