Fixup Intel flash that powers up locked

[Todd Poynor]

Nicolas Pitre wrote:

> Properly dealing with this "feature" appears to be so messy that I'm 
> starting to wonder if we should not just unconditionally unlock the 
> flash at boot time and be done with it.

Or leave all blocks locked to err on the side of safety and require 
userspace init scripts to unlock writeable partitions.

> It's only the flash used for the root filesystem which is problematic 
> anyway, right?  If so then I think there should be a mount option for 
> JFFS* such that it directly unlocks the whole of the MTD device it's 
> about to be mounted on when it's mounted read-write.  That's it.

Read-only root with writeable partitions mounted afterwards is what I 
suggest, I imagine there's reasons not to do it that way, though.

> As for the suspend case then you should probably just preserve the flash 
> lock state before suspending and restore that state upon resume.

I'm guessing the code for that would trigger the messy alarms as well...

Am finding the frob DEBUG_LOCK_BITS logic doesn't read lock status 
properly on this board's chip (blocks that appear to be writeable still 
read status non-zero).  This makes it difficult to setup the bitmap at 
suspend time.  Now, I could maintain the bitmap at each block 
lock/unlock time, but the frob code doesn't pass the eraseregion info 
(useful to understand region size and maintain per-region bitmap) to the 
chip driver (which knows whether the chip has this powers-up-locked 
property).  Alas.  I will play with this some more.

> Why are you doing this block by block? You could as well just do:
> 
> 	cfi_intelext_unlock(mtd, 0, mtd->size);
> 
> since the block walking is already performed by cfi_varsize_frob().

Aargh, that code predated the frob on multi-partition flash fix, sorry. 
  Thanks,


-- 
Todd