Numonyx NOR bug

[Leo <leo.costa77@gmail.com>]

I found a little problem with mtd drivers running on a LTIB linux 
distribution on a custom board equipped with a Freescale Coldfire and a 
Numonyx NOR Axcell M29EW flash memory. The do_erase_oneblock() function 
sometimes fails because the chip_good() functions returns zero reading a 
data word different from 0xffff. I spent some time debugging and finally 
I solved the problem adding a new chip state "FL_ERASE_STARTING" and 
setting it after the erase block command sequence as follows :

   cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi, 
cfi->device_type, NULL);
   cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi, 
cfi->device_type, NULL);
   cfi_send_gen_cmd(0x80, cfi->addr_unlock1, chip->start, map, cfi, 
cfi->device_type, NULL);
   cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi, 
cfi->device_type, NULL);
   cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi, 
cfi->device_type, NULL);
   map_write(map, CMD(0x30), adr);

   chip->state = FL_ERASE_STARTING;

   INVALIDATE_CACHE_UDELAY(map, chip,
                        adr, len,
                        chip->erase_time);

   chip->state = FL_ERASING;
   chip->erase_suspended = 0;
   chip->in_progress_block_addr = adr;

   timeo = jiffies + (HZ*20);

   for (;;) {

This works because the Numonyx chip probably does not accept the erase 
suspend command during the erase block time-out (the 50 us after the 
command sequence has been sent and before the erase starts). In fact the 
INVALIDATE_CACHE_UDELAY() macro unlocks the mutex and lets 
reading/writing functions to suspend the erasing too soon calling the 
get_chip(). With the FL_ERASE_STARTING state get_chip() does not give 
the access to reading/writing functions during the 
INVALIDATE_CACHE_UDELAY() sleeping period (chip->erase_time).
Anyone into the same problem?

Thanks for reading!
Leonardo