MTD suspend/resume bug

[Russell King <rmk@arm.linux.org.uk>]

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