linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] mtd: nand: docg4: ecc.read_page() returns 0 on uncorrectible errors
@ 2012-09-11 15:50 Mike Dunn
  2012-09-15  3:20 ` Brian Norris
  2012-09-24 15:17 ` Artem Bityutskiy
  0 siblings, 2 replies; 4+ messages in thread
From: Mike Dunn @ 2012-09-11 15:50 UTC (permalink / raw)
  To: linux-mtd; +Cc: Mike Dunn

Currently the docg4's ecc.read_page() method returns -EBADMSG when uncorrectible
bitflips occur.  This is wrong; 0 should be returned in this case.  An error
code should only be returned by this method in the case of a hardware error
(probably -EIO).

Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
---
 drivers/mtd/nand/docg4.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/docg4.c b/drivers/mtd/nand/docg4.c
index 793921e..deb718c 100644
--- a/drivers/mtd/nand/docg4.c
+++ b/drivers/mtd/nand/docg4.c
@@ -776,6 +776,8 @@ static int read_page(struct mtd_info *mtd, struct nand_chip *nand,
 	}
 
 	writew(0, docptr + DOC_DATAEND);
+	if (bits_corrected == -EBADMSG)	  /* uncorrectible errors */
+		return 0;
 	return bits_corrected;
 }
 
-- 
1.7.3.4

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] mtd: nand: docg4: ecc.read_page() returns 0 on uncorrectible errors
  2012-09-11 15:50 [PATCH] mtd: nand: docg4: ecc.read_page() returns 0 on uncorrectible errors Mike Dunn
@ 2012-09-15  3:20 ` Brian Norris
  2012-09-15 18:08   ` Mike Dunn
  2012-09-24 15:17 ` Artem Bityutskiy
  1 sibling, 1 reply; 4+ messages in thread
From: Brian Norris @ 2012-09-15  3:20 UTC (permalink / raw)
  To: Mike Dunn; +Cc: linux-mtd

On Tue, Sep 11, 2012 at 8:50 AM, Mike Dunn <mikedunn@newsguy.com> wrote:
> diff --git a/drivers/mtd/nand/docg4.c b/drivers/mtd/nand/docg4.c
> index 793921e..deb718c 100644
> --- a/drivers/mtd/nand/docg4.c
> +++ b/drivers/mtd/nand/docg4.c
> @@ -776,6 +776,8 @@ static int read_page(struct mtd_info *mtd, struct nand_chip *nand,
>         }
>
>         writew(0, docptr + DOC_DATAEND);
> +       if (bits_corrected == -EBADMSG)   /* uncorrectible errors */

s/uncorrectible/uncorrectable/

> +               return 0;
>         return bits_corrected;
>  }
>

With that change:

Acked-by: Brian Norris <computersforpeace@gmail.com>

Also, not a blocker for this patch, but this made me look elsewhere in docg4.c:

static int __init read_factory_bbt(struct mtd_info *mtd)
{
...
        status = docg4_read_page(mtd, nand, buf, 0, DOCG4_FACTORY_BBT_PAGE);
        if (status)
                goto exit;

This could cause problems if there are ever bitflips on the BBT page.
Can the factory BBT contain bitflips?

Brian

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] mtd: nand: docg4: ecc.read_page() returns 0 on uncorrectible errors
  2012-09-15  3:20 ` Brian Norris
@ 2012-09-15 18:08   ` Mike Dunn
  0 siblings, 0 replies; 4+ messages in thread
From: Mike Dunn @ 2012-09-15 18:08 UTC (permalink / raw)
  To: Brian Norris; +Cc: linux-mtd

Hi Brian, thanks for the Ack.  It seems I was careless with my own driver when I
did the bitflip patches.

BTW, the consequence of this oversight was seen when using mtdchar (e.g.,
mtd-utils 'nanddump') when uncorrectAble bitflips occurred.  The userspace app
just kept repeating the read call, because the prior call indicated that no data
was read.


On 09/14/2012 08:20 PM, Brian Norris wrote:
>> +       if (bits_corrected == -EBADMSG)   /* uncorrectible errors */
> 
> s/uncorrectible/uncorrectable/


Ha!  I actualy looked the word up in the dictionary, and either spelling is
correct.  But yours is more common.


> 
>> +               return 0;
>>         return bits_corrected;
>>  }
>>
> 
> With that change:
> 
> Acked-by: Brian Norris <computersforpeace@gmail.com>
> 
> Also, not a blocker for this patch, but this made me look elsewhere in docg4.c:
> 
> static int __init read_factory_bbt(struct mtd_info *mtd)
> {
> ...
>         status = docg4_read_page(mtd, nand, buf, 0, DOCG4_FACTORY_BBT_PAGE);
>         if (status)
>                 goto exit;
> 
> This could cause problems if there are ever bitflips on the BBT page.
> Can the factory BBT contain bitflips?


Ah, yes, thank you for catching that!!  Overlooked when docg4_read_page() was
changed to return max bitflips; status should be tested for negative value.
Should also try to recover from uncorrectable bitflips (I believe that table is
stored redundantly).

Thanks again,
Mike

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] mtd: nand: docg4: ecc.read_page() returns 0 on uncorrectible errors
  2012-09-11 15:50 [PATCH] mtd: nand: docg4: ecc.read_page() returns 0 on uncorrectible errors Mike Dunn
  2012-09-15  3:20 ` Brian Norris
@ 2012-09-24 15:17 ` Artem Bityutskiy
  1 sibling, 0 replies; 4+ messages in thread
From: Artem Bityutskiy @ 2012-09-24 15:17 UTC (permalink / raw)
  To: Mike Dunn; +Cc: linux-mtd

[-- Attachment #1: Type: text/plain, Size: 444 bytes --]

On Tue, 2012-09-11 at 08:50 -0700, Mike Dunn wrote:
> Currently the docg4's ecc.read_page() method returns -EBADMSG when uncorrectible
> bitflips occur.  This is wrong; 0 should be returned in this case.  An error
> code should only be returned by this method in the case of a hardware error
> (probably -EIO).
> 
> Signed-off-by: Mike Dunn <mikedunn@newsguy.com>

Pushed to l2-mtd.git, thanks!

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2012-09-24 15:18 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-09-11 15:50 [PATCH] mtd: nand: docg4: ecc.read_page() returns 0 on uncorrectible errors Mike Dunn
2012-09-15  3:20 ` Brian Norris
2012-09-15 18:08   ` Mike Dunn
2012-09-24 15:17 ` Artem Bityutskiy

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).