>From 0304e9618d8c3ef5360b611f881f1b1bed08be06 Mon Sep 17 00:00:00 2001 From: White Ding <b...@micron.com> Date: Thu, 24 Jul 2014 00:10:45 +0800 Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
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. As we know the status register can be refreshed, if we do some operation to trigger it, for example if we do erase/program operation to one block that is locked, then READ STATUS, the bit 7 of READ STATUS will be 0 indicate the device in 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 the device is not write protect. Suppose we checked the bit 7 of READ STATUS is 0 then judge the WP# is low (write protect), but in this case the WP# maybe high if we do erase/program operation to a locked block, so we must reset the device if we want to check the WP# low or high through STATUS READ and check bit 7. Signed-off-by: White Ding <b...@micron.com> --- drivers/mtd/nand/nand_base.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index 41167e9..22dd3aa 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -965,6 +965,15 @@ int nand_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len) chip->select_chip(mtd, chipnr); + /* + * Reset the chip. + * If we want to check the WP through READ STATUS and check the bit 7 + * we must reset the chip + * some operation can also clear the bit 7 of status register + * eg. erase/program a locked block + */ + chip->cmdfunc(mtd, NAND_CMD_RESET, -1, -1); + /* Check, if it is write protected */ if (nand_check_wp(mtd)) { pr_debug("%s: device is write protected!\n", @@ -1015,6 +1024,15 @@ int nand_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len) chip->select_chip(mtd, chipnr); + /* + * Reset the chip. + * If we want to check the WP through READ STATUS and check the bit 7 + * we must reset the chip + * some operation can also clear the bit 7 of status register + * eg. erase/program a locked block + */ + chip->cmdfunc(mtd, NAND_CMD_RESET, -1, -1); + /* Check, if it is write protected */ if (nand_check_wp(mtd)) { pr_debug("%s: device is write protected!\n", -- 1.7.9.5 White -----Original Message----- From: Brian Norris [mailto:computersforpe...@gmail.com] Sent: Tuesday, August 05, 2014 6:48 AM To: bpqw Cc: dw...@infradead.org; b32...@freescale.com; artem.bityuts...@linux.intel.com; r...@debian.org; u.kleine-koe...@pengutronix.de; ezequiel.gar...@free-electrons.com; linux-...@lists.infradead.org; linux-kernel@vger.kernel.org Subject: Re: 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.neww...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/