linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Li Yang <leoli@freescale.com>
To: Scott Wood <scottwood@freescale.com>
Cc: Artem.Bityutskiy@nokia.com, dedekind1@gmail.com,
	linuxppc-dev@lists.ozlabs.org, LiuShuo <b35362@freescale.com>,
	linux-kernel@vger.kernel.org, shuo.liu@freescale.com,
	linux-mtd@lists.infradead.org, akpm@linux-foundation.org,
	dwmw2@infradead.org
Subject: Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
Date: Mon, 19 Dec 2011 19:05:26 +0800	[thread overview]
Message-ID: <CADRPPNT-akj5KBQKdRaFrA2XpLU6-xtuRduzDYEWjv_dzVmTAA@mail.gmail.com> (raw)
In-Reply-To: <4EEB8704.8030201@freescale.com>

On Sat, Dec 17, 2011 at 1:59 AM, Scott Wood <scottwood@freescale.com> wrote=
:
> On 12/15/2011 08:44 PM, LiuShuo wrote:
>> hi Artem,
>> Could this patch be applied now and we make a independent patch for =C2=
=A0bad
>> block information
>> migration later?
>
> This patch is not safe to use without migration.

Hi Scott,

We agree it's not entirely safe without migrating the bad block flag.
But let's consider two sides of the situation.

Firstly, it's only unsafe when there is a need to re-built the Bad
Block Table from scratch(old BBT broken).  But currently there is no
easy way to do that(re-build BBT on demand), which means it's not a
common problem that we can easily address now.

Secondly, even if the previous said problem happens(BBT broken).  We
can still recover all the data if we overrule the bad block flag.
Only the card is not so good to be used again, however, it can be used
if we take the risk of losing data from errors that ECC can't
notice(low possibility too).

Finally, I don't think this is a blocker issue but a better to have enhance=
ment.

- Leo

  reply	other threads:[~2011-12-19 11:05 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-04  4:31 [PATCH 1/3] mtd/nand : use elbc_fcm_ctrl->oob to set FPAR_MS bit of FPAR shuo.liu
2011-12-04  4:31 ` [PATCH 2/3] mtd/nand : set correct length to FBCR for a non-full-page write shuo.liu
2011-12-04  4:31 ` [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip shuo.liu
2011-12-05  6:47   ` Artem Bityutskiy
2011-12-05 19:46     ` Scott Wood
2011-12-06 11:49       ` Artem Bityutskiy
2011-12-06 11:49   ` Artem Bityutskiy
2011-12-07  0:09   ` Scott Wood
2011-12-07  3:55     ` LiuShuo
2011-12-07 19:11       ` Scott Wood
2011-12-08 10:44         ` LiuShuo
2011-12-08 18:43           ` Scott Wood
2011-12-12 21:09     ` Artem Bityutskiy
2011-12-12 21:15       ` Scott Wood
2011-12-12 21:19         ` Artem Bityutskiy
2011-12-12 21:30           ` Scott Wood
2011-12-13  2:46             ` LiuShuo
2011-12-14  8:41               ` LiuShuo
2011-12-14 20:15                 ` Scott Wood
2011-12-15  4:59                   ` Li Yang
2011-12-15 17:32                     ` Scott Wood
2011-12-16  2:44                   ` LiuShuo
2011-12-16 17:59                     ` Scott Wood
2011-12-19 11:05                       ` Li Yang [this message]
2011-12-19 16:47                         ` Scott Wood
2011-12-20  9:08                           ` Li Yang
2011-12-20 19:48                             ` Scott Wood
2011-12-17 14:35             ` Artem Bityutskiy
2011-12-19 18:38               ` Scott Wood
2011-12-19 18:42                 ` Scott Wood
2011-12-14  3:41       ` LiuShuo
2011-12-14 20:53         ` Scott Wood
2011-12-05  6:50 ` [PATCH 1/3] mtd/nand : use elbc_fcm_ctrl->oob to set FPAR_MS bit of FPAR Artem Bityutskiy
  -- strict thread matches above, loose matches on Subject: below --
2011-11-24  0:41 b35362
2011-11-24  0:41 ` [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip b35362
2011-11-24  7:37   ` Li Yang-R58472
2011-11-28 17:20     ` Scott Wood
2011-11-24  7:41   ` Artem Bityutskiy
2011-11-24  7:49     ` Li Yang-R58472
2011-11-24  8:16       ` Artem Bityutskiy
2011-11-24 10:02         ` LiuShuo
2011-11-24 11:07           ` Artem Bityutskiy
2011-11-28 21:48   ` Scott Wood
2011-11-28 21:49     ` Scott Wood

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=CADRPPNT-akj5KBQKdRaFrA2XpLU6-xtuRduzDYEWjv_dzVmTAA@mail.gmail.com \
    --to=leoli@freescale.com \
    --cc=Artem.Bityutskiy@nokia.com \
    --cc=akpm@linux-foundation.org \
    --cc=b35362@freescale.com \
    --cc=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=scottwood@freescale.com \
    --cc=shuo.liu@freescale.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).