aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorShashi Rao <shashi@sun.com>2007-03-28 18:56:28 -0400
committerDavid Woodhouse <dwmw2@infradead.org>2007-04-17 14:11:20 -0400
commite6be133b68ae2c8f89d46da25ed7b31b84793e7e (patch)
tree78ae9a2f10daa5e21c1761039146dffad1377a09
parentc2aecda79cd872679b9b11f9e59d797fb4c7d677 (diff)
[MTD] Fix fwh_lock locking
This is on a custom board with a mapping driver access to an ST M50LPW080 chip. This chip is probed successfully with do_map_probe("jedec_probe",...). If I use the mtdchar interface to perform unlock->erase->program->lock on any of the 16 eraseblocks in the chip, the chip is left in FL_STATUS mode while the data structures believe that the chip is in FL_READY mode. Hence, any subsequent reads to any flash byte results in 0x80 being read. Signed-off-by: Shashi Rao <shashi@sun.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
-rw-r--r--drivers/mtd/chips/fwh_lock.h3
1 files changed, 2 insertions, 1 deletions
diff --git a/drivers/mtd/chips/fwh_lock.h b/drivers/mtd/chips/fwh_lock.h
index 77303ce5dcf1..ab44f2b996f8 100644
--- a/drivers/mtd/chips/fwh_lock.h
+++ b/drivers/mtd/chips/fwh_lock.h
@@ -65,11 +65,12 @@ static int fwh_xxlock_oneblock(struct map_info *map, struct flchip *chip,
65 return ret; 65 return ret;
66 } 66 }
67 67
68 chip->oldstate = chip->state;
68 chip->state = xxlt->state; 69 chip->state = xxlt->state;
69 map_write(map, CMD(xxlt->val), adr); 70 map_write(map, CMD(xxlt->val), adr);
70 71
71 /* Done and happy. */ 72 /* Done and happy. */
72 chip->state = FL_READY; 73 chip->state = chip->oldstate;
73 put_chip(map, chip, adr); 74 put_chip(map, chip, adr);
74 spin_unlock(chip->mutex); 75 spin_unlock(chip->mutex);
75 return 0; 76 return 0;