lock bit and erase errors
Josh Boyer
jdub at us.ibm.com
Mon Mar 14 14:20:16 EST 2005
On Mon, 2005-03-14 at 13:08 -0600, Josh Boyer wrote:
> Caveat: I am using some pretty old code in this case, but the current
> code is also questionable so bear with me.
>
> I can't for the life of me figure out what the following code from
> do_erase_oneblock cfi_cmdset_0001.c is doing:
>
> /* check for lock bit */
> if (status & CMD(0x3a)) {
> unsigned char chipstatus = status;
> if (status != CMD(status & 0xff)) {
> int i = cfi->interleave;
> for (i = 1; i<cfi->interleave; i++) {
> chipstatus |= status >> (cfi->device_type * 8);
> }
> printk(KERN_WARNING "Status is not identical for all chips: 0x%x. Merging to give 0x%02x\n", status, chipstatus);
> }
>
>
> My device is a 16-bit device, the interleave is 1, and I have a few
> blocks with the lock bit on. When I do a write to /dev/mtdblock/0/0, an
> erase is attempted. When I run an older version of this code, I get:
>
> "Status not identical for all chips: 0xa200. Merging to give 0x00"
>
> What I don't understand is how any of the above code is expected to
> work. A 1 byte variable (chipstatus) is assigned a 4 byte value
> (status), which gets truncated. Then status is shifted by 16 bits (in
> my case), which still means chipstatus is still 0. When all is said and
> done, I get the merging printk but none of the checks below this code
> match. That doesn't seem right...
>
> I hacked the older code for my specific instance to do:
>
> chipstatus = status >> 8;
>
> and I get the proper return code for my situation (-EROFS). I still
> don't get an error in the application writing to /dev/mtdblock/0/0, but
> at least the chip driver is actually returning an error.
>
> Any ideas?
>
Urm, I should also point out that I have intentionally locked the
eraseblocks on this device, so I _expect_ it to fail. But the driver
didn't return a bad return code, which is what I'm confused about.
And I'm also confused as to why the app didn't get a bad return code
even when I "fixed" the driver to error out. But one thing at a time.
josh
More information about the linux-mtd
mailing list