MTD suspend/resume bug

MTD suspend/resume bug

[Russell King]

People,

There appears to be  a bug in the Intel CFI suspend/resume code in
2.6.10-rc1.

Looking at cfi_intelext_suspend() and cfi_intelext_resume(), consider
what happens if we suspend a MTD device, resume it, and then suspend
it again, with an intermediate switch to FL_STATUS mode.

Initial state:

	cfi->oldstate = FL_READY;
	cfi->state = FL_STATUS; (eg)

First suspend:

	cfi->oldstate = FL_STATUS;
	cfi->state = FL_PM_SUSPENDED;

Resume:

	cfi->state = FL_READY;

	Note: we do not touch cfi->oldstate here.

<something here sets cfi->state to FL_STATUS>

Second suspend:

	At this point, cfi->state == FL_STATUS, cfi->oldstate == FL_STATUS.
	Since cfi->oldstate != FL_READY, we do not set cfi->oldstate nor
	cfi->state.

Resume occurs.  Flash chip was powered off so is now in READY mode,
but MTD thinks its in FL_STATUS and complains about bad chip status:

Waiting for chip to be ready timed out. Status 41927a42
Write of 83 bytes at 0x00cf34e4 failed. returned -5, retlen 0
Not marking the space at 0x00cf34e4 as dirty because the flash driver returned retlen zero
Waiting for chip to be ready timed out. Status e0021985
Error reading node from 0x00917d88: -5

Shouldn't the resume function set both cfi->oldstate and cfi->state
to FL_READY ?

-- 
Russell King

Re: MTD suspend/resume bug

[David Woodhouse]

On Wed, 2004-11-10 at 20:43 +0000, Russell King wrote:
> Shouldn't the resume function set both cfi->oldstate and cfi->state
> to FL_READY ?

Yes, it probably should. Can you try the (untested) v1.162 from CVS?

You mentioned that we should probably be waiting for any operation to
complete, instead of returning -EAGAIN. Once upon a time, I think these
routines weren't allowed to sleep -- I assume that's changed now?

Still, the upper layers are supposed to have quiesced everything so
there shouldn't _be_ anything happening, surely? Doing it that way may
allow us to just switch to using get_chip() nicely like everyone else
does... I wouldn't be averse to it if someone cares enough to implement
it.

-- 
dwmw2