All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek <marex@denx.de>
To: David Woodhouse <dwmw2@infradead.org>
Cc: dedekind1@gmail.com, tharvey@gateworks.com,
	stable@vger.kernel.org, Huang Shijie <b32955@freescale.com>,
	linux-mtd@lists.infradead.org, computersforpeace@gmail.com
Subject: Re: [PATCH V2] mtd: gpmi: fix the ecc regression
Date: Fri, 25 Oct 2013 15:22:12 +0200	[thread overview]
Message-ID: <1759334.BdWLZMGAMu@w510> (raw)
In-Reply-To: <1382703654.8522.114.camel@shinybook.infradead.org>

On Friday 25 of October 2013 13:20:54 David Woodhouse wrote:
> On Fri, 2013-10-25 at 13:03 +0100, David Woodhouse wrote:
> > So... what if someone has already shipped the new chips that require
> > stronger ECC, without realising that legacy_set_geometry() is
> > insufficient? (And is legacy_set_geometry *actually* doing precisely the
> > same as 3.10/3.11?)
> 
> Answering my own question: If the required ECC strength is known and the
> legacy ECC layout is insufficient, that's caused a failure since commit
> 92d0e09abeebd ("mtd: gpmi: add sanity check for the ECC") in 3.9, so I'm
> not worried about supporting that.
> 
> And legacy_set_geometry() *is* doing what 3.11 did, verbatim.
> 
> So the question is whether we want this "if legacy is sufficient then
> use it else use the new method" that you offer in v2 of the patch, or if
> a device-tree property is the better way to do it.
> 
> I'm actually slightly in favour of the device-tree property. But since
> 3.12 is imminent I think the *best* option is just to do this to
> preserve the 3.11 behaviour, and worry about getting it right for 3.13:
> 
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c index 59ab069..a9830ff 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> @@ -349,7 +349,7 @@ static int legacy_set_geometry(struct gpmi_nand_data
> *this)
> 
>  int common_nfc_set_geometry(struct gpmi_nand_data *this)
>  {
> -	return set_geometry_by_ecc_info(this) ? 0 : legacy_set_geometry(this);
> +	return legacy_set_geometry(this);
>  }
> 
>  struct dma_chan *get_dma_chan(struct gpmi_nand_data *this)

I can confirm this patch fixes the regression, UBIFS can now again be mounted on 
3.12rc6 . Thanks!

Acked-by: Marek Vasut <marex@denx.de>

On M28EVK with NAND device:
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron MT29F2G08ABAEAWP)
NAND device: 256MiB, SLC, page size: 2048, OOB size: 64

Tested-by: Marek Vasut <marex@denx.de>

Cheers!

  reply	other threads:[~2013-10-25 13:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-24  8:14 [PATCH V2] mtd: gpmi: fix the ecc regression Huang Shijie
2013-10-24  8:48 ` [PATCH v2 fix] " Huang Shijie
2013-10-24 22:19   ` Brian Norris
2013-10-25 13:36     ` David Woodhouse
2013-10-25 12:03 ` [PATCH V2] " David Woodhouse
2013-10-25 12:20   ` David Woodhouse
2013-10-25 13:22     ` Marek [this message]
2013-10-26  1:33     ` Huang Shijie
2013-10-25 13:29       ` David Woodhouse
2013-10-25 13:38         ` Marek
2013-10-26  1:41         ` Huang Shijie
2013-10-25 14:08           ` David Woodhouse
2013-10-25 17:08             ` Brian Norris

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=1759334.BdWLZMGAMu@w510 \
    --to=marex@denx.de \
    --cc=b32955@freescale.com \
    --cc=computersforpeace@gmail.com \
    --cc=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=stable@vger.kernel.org \
    --cc=tharvey@gateworks.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.