Re: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
On Tue, Aug 05, 2014 at 01:54:07AM +, bpqw wrote: > From 0304e9618d8c3ef5360b611f881f1b1bed08be06 Mon Sep 17 00:00:00 2001 > From: White Ding > 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 Thanks. Queued to l2-mtd.git/next. 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/
RE: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
>From 0304e9618d8c3ef5360b611f881f1b1bed08be06 Mon Sep 17 00:00:00 2001
From: White Ding
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
---
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 +, 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
> > 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 ref
Re: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
Hi, On Mon, Jul 28, 2014 at 07:46:51AM +, 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 > > 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/
RE: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
Hi Brain, How about my patch? Do you have any other doubts? Br White Ding -Original Message- From: bpqw Sent: Monday, July 28, 2014 3:47 PM To: Brian Norris; 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 Brain, >> 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 > 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. Br White Ding EBU APAC Application Engineering Tel:86-21-38997078 Mobile: 86-13761729112 Address: No 601 Fasai Rd, Waigaoqiao Free Trade Zone Pudong, Shanghai, China -Original Message- From: Brian Norris [mailto:computersforpe...@gmail.com] Sent: Monday, July 28, 2014 2:10 PM 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 White, You've responded to one of my messages, but your mail server is also sending bounce replies. You might want to contact your I.T. about this. (I'll let you know if I ever stop getting bounces.) On Thu, Jul 24, 2014 at 01:00:01AM +, 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. 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: commit 7d70f334ad2bf1b3aaa1f0699c0f442e14bcc9e0 Author: Vimal Singh 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? > Signed-off-by: White Ding > --- > drivers/mtd/nand/nand_base.c | 18 ++ > 1 file changed, 18 in
RE: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
Hi Brain, How about my patch do you have any other proposal? Br White Ding EBU APAC Application Engineering Tel:86-21-38997078 Mobile: 86-13761729112 Address: No 601 Fasai Rd, Waigaoqiao Free Trade Zone Pudong, Shanghai, China -Original Message- From: bpqw Sent: Monday, July 28, 2014 3:47 PM To: Brian Norris; 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 Brain, >> 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 > 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. Br White Ding EBU APAC Application Engineering Tel:86-21-38997078 Mobile: 86-13761729112 Address: No 601 Fasai Rd, Waigaoqiao Free Trade Zone Pudong, Shanghai, China -Original Message- From: Brian Norris [mailto:computersforpe...@gmail.com] Sent: Monday, July 28, 2014 2:10 PM 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 White, You've responded to one of my messages, but your mail server is also sending bounce replies. You might want to contact your I.T. about this. (I'll let you know if I ever stop getting bounces.) On Thu, Jul 24, 2014 at 01:00:01AM +, 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. 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: commit 7d70f334ad2bf1b3aaa1f0699c0f442e14bcc9e0 Author: Vimal Singh 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); w
RE: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
Hi Brain, >> 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 > 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. Br White Ding EBU APAC Application Engineering Tel:86-21-38997078 Mobile: 86-13761729112 Address: No 601 Fasai Rd, Waigaoqiao Free Trade Zone Pudong, Shanghai, China -Original Message- From: Brian Norris [mailto:computersforpe...@gmail.com] Sent: Monday, July 28, 2014 2:10 PM 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 White, You've responded to one of my messages, but your mail server is also sending bounce replies. You might want to contact your I.T. about this. (I'll let you know if I ever stop getting bounces.) On Thu, Jul 24, 2014 at 01:00:01AM +, 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. 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: commit 7d70f334ad2bf1b3aaa1f0699c0f442e14bcc9e0 Author: Vimal Singh 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? > Signed-off-by: White Ding > --- > 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
Re: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
Hi White,
You've responded to one of my messages, but your mail server is also
sending bounce replies. You might want to contact your I.T. about this.
(I'll let you know if I ever stop getting bounces.)
On Thu, Jul 24, 2014 at 01:00:01AM +, 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.
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:
commit 7d70f334ad2bf1b3aaa1f0699c0f442e14bcc9e0
Author: Vimal Singh
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?
> Signed-off-by: White Ding
> ---
> 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",
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/
RE: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
>OK, I won't drop them yet. >As you note, there's no user-space support. There's actually no one using them >even in the kernel, which is why I considered dropping them. >If you want to use them, find a proper way to use them then! (I'm not >sure: do they match with mtd_lock() / ioctl(MEMLOCK) interface?) How about my patch, Do you think there is any other need to change? White -- 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/
Re: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
On Thu, Jul 24, 2014 at 07:54:41AM +, Pekon Gupta wrote:
> >On Thu, Jul 24, 2014 at 01:00:01AM +, bpqw wrote:
> >I don't see any in-tree users of nand_{un,}lock(). I recently caught a
> >bug in nand_lock() via inspection (still need to send a fix), but I was
> >considering dropping the functions entirely.
> >
> >I presume you have some out-of-tree driver that uses these functions,
> >then?
> >
> Please don't drop nand_{unlock, lock} interfaces at-least for sometime.
> I remember there were some users trying to use these for secure
> applications. But due to lack of proper userland utility support they
> probably dropped the idea.
OK, I won't drop them yet.
> Good to have this added as part of mtd-utils package, and then let it live
> for some more time.
As you note, there's no user-space support. There's actually no one
using them even in the kernel, which is why I considered dropping them.
If you want to use them, find a proper way to use them then! (I'm not
sure: do they match with mtd_lock() / ioctl(MEMLOCK) interface?)
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/
RE: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
>From: Brian Norris
>
>Hi White,
>
>On Thu, Jul 24, 2014 at 01:00:01AM +, 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.
>>
>> Signed-off-by: White Ding
>> ---
>> 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)
>[...]
>> @@ -1015,6 +1024,15 @@ int nand_lock(struct mtd_info *mtd, loff_t ofs,
>> uint64_t len)
>[...]
>
>I don't see any in-tree users of nand_{un,}lock(). I recently caught a
>bug in nand_lock() via inspection (still need to send a fix), but I was
>considering dropping the functions entirely.
>
>I presume you have some out-of-tree driver that uses these functions,
>then?
>
Please don't drop nand_{unlock, lock} interfaces at-least for sometime.
I remember there were some users trying to use these for secure
applications. But due to lack of proper userland utility support they
probably dropped the idea.
Good to have this added as part of mtd-utils package, and then let it live
for some more time.
with regards, Pekon
--
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/
Re: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
On Wed, Jul 23, 2014 at 06:27:30PM -0700, Brian Norris wrote: > Hi White, > > On Thu, Jul 24, 2014 at 01:00:01AM +, bpqw wrote: [...] And...I just got a rejection email from micron.com: The error that the other server returned was: 550 5.1.1 ... ... User unknown I'm not sure how to get a reply to the submitter now. Perhaps he reads LKML. 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/
Re: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
Hi White,
On Thu, Jul 24, 2014 at 01:00:01AM +, 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.
>
> Signed-off-by: White Ding
> ---
> 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)
[...]
> @@ -1015,6 +1024,15 @@ int nand_lock(struct mtd_info *mtd, loff_t ofs,
> uint64_t len)
[...]
I don't see any in-tree users of nand_{un,}lock(). I recently caught a
bug in nand_lock() via inspection (still need to send a fix), but I was
considering dropping the functions entirely.
I presume you have some out-of-tree driver that uses these functions,
then?
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/
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.
Signed-off-by: White Ding
---
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
Br
White Ding
EBU APAC Application Engineering
Tel:86-21-38997078
Mobile: 86-13761729112
Address: No 601 Fasai Rd, Waigaoqiao Free Trade Zone Pudong, Shanghai, China
--
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/
