linux-kernel - Re: Subject: [PATCH 1/1] mtd:nand:fix nand

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 27 Jul 2014 23:10:06 -0700
From:	Brian Norris <computersforpeace@...il.com>
To:	bpqw <bpqw@...ron.com>
Cc:	"dwmw2@...radead.org" <dwmw2@...radead.org>,
	"b32955@...escale.com" <b32955@...escale.com>,
	"artem.bityutskiy@...ux.intel.com" <artem.bityutskiy@...ux.intel.com>,
	"ron@...ian.org" <ron@...ian.org>,
	"u.kleine-koenig@...gutronix.de" <u.kleine-koenig@...gutronix.de>,
	"ezequiel.garcia@...e-electrons.com" 
	<ezequiel.garcia@...e-electrons.com>,
	"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.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 +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.

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 <vimal.newwork@...il.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?

> Signed-off-by: White Ding <bpqw@...ron.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",

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/