linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Tokunori Ikegami <ikegami.t@gmail.com>
To: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Brian Norris <computersforpeace@gmail.com>,
	Marek Vasut <marek.vasut@gmail.com>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	linux-mtd@lists.infradead.org
Subject: Re: [PATCH 2/2] mtd: cfi_cmdset_0002: fix delayed error detection on HyperFlash
Date: Mon, 7 Oct 2019 05:54:46 +0900	[thread overview]
Message-ID: <b4d19e66-83e6-d7a2-8aa6-85034460725e@gmail.com> (raw)
In-Reply-To: <b146c469-6cc3-885e-3e8e-ff7a5fa8dcd4@cogentembedded.com>

Hi,

On 2019/10/04 3:34, Sergei Shtylyov wrote:
> The commit 4844ef80305d ("mtd: cfi_cmdset_0002: Add support for polling
> status register") added checking for the status register error bits into
> chip_good() to only return 1 if these bits are zero. Unfortunately, this
> means that polling using chip_good() always reaches a time-out condition
> when erase or program failure bits are set. I think the status register
> error checking should be fully delegated to cfi_check_err_status() that
> should return whether any error bits were set or not...
>
> Fixes: 4844ef80305d ("mtd: cfi_cmdset_0002: Add support for polling status register")
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
>   drivers/mtd/chips/cfi_cmdset_0002.c |   55 +++++++++++++++++++-----------------
>   1 file changed, 30 insertions(+), 25 deletions(-)
>
> Index: linux/drivers/mtd/chips/cfi_cmdset_0002.c
> ===================================================================
> --- linux.orig/drivers/mtd/chips/cfi_cmdset_0002.c
> +++ linux/drivers/mtd/chips/cfi_cmdset_0002.c
> @@ -123,14 +123,14 @@ static int cfi_use_status_reg(struct cfi
>   		(extp->SoftwareFeatures & poll_mask) == CFI_POLL_STATUS_REG;
>   }
>   
> -static void cfi_check_err_status(struct map_info *map, struct flchip *chip,
> -				 unsigned long adr)
> +static int cfi_check_err_status(struct map_info *map, struct flchip *chip,
> +				unsigned long adr)
>   {
>   	struct cfi_private *cfi = map->fldrv_priv;
>   	map_word status;
>   
>   	if (!cfi_use_status_reg(cfi))
> -		return;
> +		return 0;
>   
>   	cfi_send_gen_cmd(0x70, cfi->addr_unlock1, chip->start, map, cfi,
>   			 cfi->device_type, NULL);
> @@ -138,7 +138,7 @@ static void cfi_check_err_status(struct
>   
>   	/* The error bits are invalid while the chip's busy */
>   	if (!map_word_bitsset(map, status, CMD(CFI_SR_DRB)))
> -		return;
> +		return 0;
>   
>   	if (map_word_bitsset(map, status, CMD(0x3a))) {
>   		unsigned long chipstatus = MERGESTATUS(status);
> @@ -155,7 +155,9 @@ static void cfi_check_err_status(struct
>   		if (chipstatus & CFI_SR_SLSB)
>   			pr_err("%s sector write protected, status %lx\n",
>   			       map->name, chipstatus);
> +		return 1;
Is it okay to be returned 1 for the errors CFI_SR_WBASB and CFI_SR_SLSB 
also?
Before the change only CFI_SR_ESB and CFI_SR_PSB were checked by 
chip_good().
>   	}
> +	return 0;
>   }
>   
>   /* #define DEBUG_CFI_FEATURES */
> @@ -852,20 +854,16 @@ static int __xipram chip_good(struct map
>   
>   	if (cfi_use_status_reg(cfi)) {
>   		map_word ready = CMD(CFI_SR_DRB);
> -		map_word err = CMD(CFI_SR_PSB | CFI_SR_ESB);
> +
>   		/*
>   		 * For chips that support status register, check device
> -		 * ready bit and Erase/Program status bit to know if
> -		 * operation succeeded.
> +		 * ready bit
>   		 */
>   		cfi_send_gen_cmd(0x70, cfi->addr_unlock1, chip->start, map, cfi,
>   				 cfi->device_type, NULL);
>   		curd = map_read(map, addr);
>   
> -		if (map_word_andequal(map, curd, ready, ready))
> -			return !map_word_bitsset(map, curd, err);
> -
> -		return 0;
> +		return map_word_andequal(map, curd, ready, ready);
>   	}
>   
>   	oldd = map_read(map, addr);
> @@ -1703,8 +1701,11 @@ static int __xipram do_write_oneword_onc
>   			break;
>   		}
>   
> -		if (chip_good(map, chip, adr, datum))
> +		if (chip_good(map, chip, adr, datum)) {
> +			if (cfi_check_err_status(map, chip, adr))
> +				ret = -EIO;
>   			break;
> +		}
>   
>   		/* Latency issues. Drop the lock, wait a while and retry */
>   		UDELAY(map, chip, adr, 1);
> @@ -1777,7 +1778,6 @@ static int __xipram do_write_oneword_ret
>   	ret = do_write_oneword_once(map, chip, adr, datum, mode, cfi);
>   	if (ret) {
>   		/* reset on all failures. */
> -		cfi_check_err_status(map, chip, adr);
>   		map_write(map, CMD(0xF0), chip->start);
>   		/* FIXME - should have reset delay before continuing */
>   
> @@ -1974,12 +1974,17 @@ static int __xipram do_write_buffer_wait
>   		 */
>   		if (time_after(jiffies, timeo) &&
>   		    !chip_good(map, chip, adr, datum)) {
> +			pr_warn("MTD %s(): software timeout, address:0x%.8lx.\n",
> +				__func__, adr);

Is there any reason to change the message to use pr_warn() from pr_err()?
In the past it was changed to use pr_err() from printk(KERN_WARNING) as 
mentioned by the maintainer.

Regards,
Ikegami

>   			ret = -EIO;
>   			break;
>   		}
>   
> -		if (chip_good(map, chip, adr, datum))
> +		if (chip_good(map, chip, adr, datum)) {
> +			if (cfi_check_err_status(map, chip, adr))
> +				ret = -EIO;
>   			break;
> +		}
>   
>   		/* Latency issues. Drop the lock, wait a while and retry */
>   		UDELAY(map, chip, adr, 1);
> @@ -2075,12 +2080,8 @@ static int __xipram do_write_buffer(stru
>   				chip->word_write_time);
>   
>   	ret = do_write_buffer_wait(map, chip, adr, datum);
> -	if (ret) {
> -		cfi_check_err_status(map, chip, adr);
> +	if (ret)
>   		do_write_buffer_reset(map, chip, cfi);
> -		pr_err("MTD %s(): software timeout, address:0x%.8lx.\n",
> -		       __func__, adr);
> -	}
>   
>   	xip_enable(map, chip, adr);
>   
> @@ -2275,9 +2276,9 @@ retry:
>   		udelay(1);
>   	}
>   
> -	if (!chip_good(map, chip, adr, datum)) {
> +	if (!chip_good(map, chip, adr, datum) ||
> +	    cfi_check_err_status(map, chip, adr)) {
>   		/* reset on all failures. */
> -		cfi_check_err_status(map, chip, adr);
>   		map_write(map, CMD(0xF0), chip->start);
>   		/* FIXME - should have reset delay before continuing */
>   
> @@ -2471,8 +2472,11 @@ static int __xipram do_erase_chip(struct
>   			chip->erase_suspended = 0;
>   		}
>   
> -		if (chip_good(map, chip, adr, map_word_ff(map)))
> +		if (chip_good(map, chip, adr, map_word_ff(map))) {
> +			if (cfi_check_err_status(map, chip, adr))
> +				ret = -EIO;
>   			break;
> +		}
>   
>   		if (time_after(jiffies, timeo)) {
>   			printk(KERN_WARNING "MTD %s(): software timeout\n",
> @@ -2487,7 +2491,6 @@ static int __xipram do_erase_chip(struct
>   	/* Did we succeed? */
>   	if (ret) {
>   		/* reset on all failures. */
> -		cfi_check_err_status(map, chip, adr);
>   		map_write(map, CMD(0xF0), chip->start);
>   		/* FIXME - should have reset delay before continuing */
>   
> @@ -2568,8 +2571,11 @@ static int __xipram do_erase_oneblock(st
>   			chip->erase_suspended = 0;
>   		}
>   
> -		if (chip_good(map, chip, adr, map_word_ff(map)))
> +		if (chip_good(map, chip, adr, map_word_ff(map))) {
> +			if (cfi_check_err_status(map, chip, adr))
> +				ret = -EIO;
>   			break;
> +		}
>   
>   		if (time_after(jiffies, timeo)) {
>   			printk(KERN_WARNING "MTD %s(): software timeout\n",
> @@ -2584,7 +2590,6 @@ static int __xipram do_erase_oneblock(st
>   	/* Did we succeed? */
>   	if (ret) {
>   		/* reset on all failures. */
> -		cfi_check_err_status(map, chip, adr);
>   		map_write(map, CMD(0xF0), chip->start);
>   		/* FIXME - should have reset delay before continuing */
>   
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2019-10-06 20:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-03 18:29 [PATCH 0/2] Fix the HyperFlash support in the AMD/Fujitsu/Spansion CFI driver Sergei Shtylyov
2019-10-03 18:32 ` [PATCH 1/2] mtd: cfi_cmdset_0002: only check errors when ready in cfi_check_err_status() Sergei Shtylyov
2019-10-03 18:34 ` [PATCH 2/2] mtd: cfi_cmdset_0002: fix delayed error detection on HyperFlash Sergei Shtylyov
2019-10-06 20:54   ` Tokunori Ikegami [this message]
2019-10-11 12:03     ` Sergei Shtylyov
2019-10-13  3:35       ` Tokunori Ikegami
2019-10-16  6:33   ` Vignesh Raghavendra
2019-10-28 19:15     ` Sergei Shtylyov
2019-10-30 15:35       ` Vignesh Raghavendra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b4d19e66-83e6-d7a2-8aa6-85034460725e@gmail.com \
    --to=ikegami.t@gmail.com \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marek.vasut@gmail.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=sergei.shtylyov@cogentembedded.com \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).