lkml.org 
[lkml]   [2014]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
Hi,

On Mon, Jul 28, 2014 at 07:46:51AM +0000, bpqw wrote:
> >> Do nand reset before write protect check If we want to check the WP#
> >> low or high through STATUS READ and check bit 7, we must reset the
> >> device, other operation (eg.erase/program a locked block) can also
> >> clear the bit 7 of status register.
> >This description doesn't really tell me why we need this patch.
> If we want to use the lock/unlock function, we must confirm the WP# is high, if the WP# is low, the write protect is provided by WP#, we don't need LOKC/UNLOCK function.
> So before we use the LOCK/UNLOCK function we must confirm the WP# is high.
> We can check the WP# is high or low through READ STATUS and check the bit 7, but this only correct when we READ STATUS directly after RESET or Power On.
> If we don't add this patch, We can't check the WP# high or low just through READ STATUS and check bit7.
>
> >First of all, where is the 'lock' sequence specified? I see the commit that introduced nand_lock() (without any users) which says Micron parts support it, but I don't see it documented in the datasheet:
> The LOCK/UNLOCK feature not apply all micron nand, only 1.8V device have this feature.
>
> > commit 7d70f334ad2bf1b3aaa1f0699c0f442e14bcc9e0
> > Author: Vimal Singh <vimal.newwork@gmail.com>
> > Date: Mon Feb 8 15:50:49 2010 +0530
>
> > mtd: nand: add lock/unlock routines
>
> >Now, supposing this is documented somewhere, are you seeing some kind of out-of-spec behavior? Is this a controller quirk you're seeing? Why should I need to reset the chip? I would presume that
>
> > chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1);
>
> >would refresh the status properly. Is that not the case?
> chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1) can refresh the status properly, but we must do some operation to trigger it.
> For example if we do rease/program operation to a block that is locked, then READ STATUS, the bit 7 will be 0 that indicate the device is write protect.
> Then if we do erase/program operation to another block that is unlocked, the bit 7 of READ STATUS will be 1 indicate that the device is not write protect.
>
> Now if we don't do any operation just through chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1); to check the WP# is high or low.
> Suppose we check the bit 7 of READ STATUS is 0 then we judge the WP# is low (write protect), but in this case the WP# may be high if we do erase/program operation to a locked block.

Thanks for the explanations. I think the patch is probably OK, then. Can
you send a new version with a more complete description in the commit
message?

Brian


\
 
 \ /
  Last update: 2014-08-05 01:21    [W:0.109 / U:2.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site