From: Artem Bityutskiy <dedekind1@gmail.com>
To: Ivan Djelic <ivan.djelic@parrot.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
Brian Norris <norris@broadcom.com>,
Matthieu CASTET <matthieu.castet@parrot.com>
Subject: Re: dangerous NAND_BBT_SCANBYTE1AND6
Date: Fri, 22 Apr 2011 11:23:36 +0300 [thread overview]
Message-ID: <1303460616.2757.52.camel@localhost> (raw)
In-Reply-To: <20110421171046.GA790@parrot.com>
On Thu, 2011-04-21 at 19:10 +0200, Ivan Djelic wrote:
> On Thu, Apr 21, 2011 at 04:52:59PM +0100, Matthieu Castet wrote:
> > Hi,
> >
> > I believe NAND_BBT_SCANBYTE1AND6 behavior is very dangerous.
> > We have a ST flash where ecc where but on bit 5 and 6.
> > With new kernel all block are bad.
> >
> > Is this option is really needed ?
> > ST datasheet say [1]. We already check the first Word.
> > Why do we need to check the 6th Byte ?
>
> I agree with Matthieu, NAND_BBT_SCANBYTE1AND6 code also seems wrong to me.
This just means that we need a better way for drivers to inform the
generic code about how exactly blocks are marked as bad. Probably
drivers could describe this with a data structure, and sometimes even
provide a "is_block_bad()" function.
The options seem to be not enough.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
next prev parent reply other threads:[~2011-04-22 8:26 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-21 15:52 dangerous NAND_BBT_SCANBYTE1AND6 Matthieu CASTET
2011-04-21 17:10 ` Ivan Djelic
2011-04-22 4:50 ` Brian Norris
2011-04-22 8:23 ` Artem Bityutskiy [this message]
2011-04-22 8:53 ` Matthieu CASTET
2011-04-22 9:28 ` Artem Bityutskiy
2011-04-21 17:33 ` Brian Norris
2011-04-22 9:02 ` Matthieu CASTET
2011-04-26 7:30 ` Ricard Wanderlof
2011-05-24 1:09 ` Brian Norris
2011-05-25 16:41 ` Ivan Djelic
2011-05-25 18:04 ` Atlant Schmidt
2011-05-25 18:31 ` Ivan Djelic
2011-05-26 7:09 ` Ricard Wanderlof
2011-05-26 7:58 ` Ivan Djelic
2011-05-26 7:07 ` Ricard Wanderlof
2011-05-26 7:57 ` Ivan Djelic
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=1303460616.2757.52.camel@localhost \
--to=dedekind1@gmail.com \
--cc=ivan.djelic@parrot.com \
--cc=linux-mtd@lists.infradead.org \
--cc=matthieu.castet@parrot.com \
--cc=norris@broadcom.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.