flash status after unlocking

Hi all,

it appears that cfi flash unlocking routines always leaves a flash chip in status mode (if CONFIG_MTD_XIP is not set).
But in some cases it is desired that the chip remains in read array mode, for linear cramfs at least.
So I've added code to put a chip in read array mode after unlocking, see patch below (the patch against 2.4 kernel, sorry), tested on OMAP1610. The patch is for Intel's command set only, though it is easy to add the fix to others. If no complaints for the fix I can test it with the latest kernel and submit a patch.

Thanks,
Dmitry

diff -upr linux-2.4.orig/drivers/mtd/chips/cfi_cmdset_0001.c linux-2.4/drivers/mtd/chips/cfi_cmdset_0001.c
@@ -1920,6 +1920,13 @@ static int __xipram do_xxlock_oneblock(s
       /* Done and happy. */
       chip->state = FL_STATUS;
       xip_enable(map, chip, adr);
+
+#ifndef CONFIG_MTD_XIP
+       if (chip->state != FL_POINT && chip->state != FL_READY) {
+               map_write(map, CMD(0xff), adr);
+               chip->state = FL_READY;
+       }
+#endif
       put_chip(map, chip, adr);
       spin_unlock(chip->mutex);
       return 0;

Please don't do that.

The thing is that most MTD methods have the same issue like write for example.

If you're using the flash for linear cramfs without the MTD XIP support then you probably already know that you must pay special attention to how you use MTD in parallel with linear cramfs. Therefore if you must unlock the flash for whatever reason that's certainly because you want to erase and/or write the flash which will have the same remain-in-status-mode issue.

In those cases the best line of action is to always read back a bit from the flash to manually force it back into array mode. Something like:

	flash-unlock /dev/mtd2 && dd if=/dev/mtd2 of=/dev/null count=1

Sames goes for flash write, lock, erase, etc.

This way the driver doesn't need to be modified for this very particular usage case.

Nicolas