All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
Cc: Fabio Estevam <fabio.estevam@freescale.com>,
	linux-mtd@lists.infradead.org,
	Sascha Hauer <kernel@pengutronix.de>,
	Scott Wood <scottwood@freescale.com>,
	David Woodhouse <dwmw2@infradead.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: mtd: nand: mxc: oobfree layout?
Date: Wed, 21 Nov 2012 10:25:40 +0100	[thread overview]
Message-ID: <20121121092540.GP10369@pengutronix.de> (raw)
In-Reply-To: <880504158.1762783.1353441918369.JavaMail.root@advansee.com>

On Tue, Nov 20, 2012 at 09:05:18PM +0100, Benoît Thébaudeau wrote:
> Dear Sascha Hauer,
> 
> I've seen in the history of mxc_nand.c that you have worked on the
> nand_ecclayout structs. The following things look abnormal. Can you confirm?
>  - nandv1_hw_eccoob_smallpage and nandv2_hw_eccoob_smallpage:
>     * Why are bytes 0 and 1 in oobfree? These bytes are used for bad block
>       information on the 16-bit variants of these 512-byte-page NANDs.

This is probably a bug. Very few people seem to use 16bit flashes.

>  - nandv1_hw_eccoob_largepage:
>     * According to the i.MX31 reference manual, the BI bytes of the spare area
>       buffers are not free to use. So why are bytes 5, 11, 27, 43 and 59 in
>       oobfree? On the contrary, if this note is a mistake in the RM, then why
>       are bytes 21, 37 and 53 not in oobfree?
>  - nandv2_hw_eccoob_smallpage, nandv2_hw_eccoob_largepage and
>    nandv2_hw_eccoob_4k:
>     * Why is byte 6 not in oobfree?

Probably bugs aswell. Most people do not use filesystems requiring OOB
data anymore, so bugs may stay uncovered for longer.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

WARNING: multiple messages have this Message-ID (diff)
From: s.hauer@pengutronix.de (Sascha Hauer)
To: linux-arm-kernel@lists.infradead.org
Subject: mtd: nand: mxc: oobfree layout?
Date: Wed, 21 Nov 2012 10:25:40 +0100	[thread overview]
Message-ID: <20121121092540.GP10369@pengutronix.de> (raw)
In-Reply-To: <880504158.1762783.1353441918369.JavaMail.root@advansee.com>

On Tue, Nov 20, 2012 at 09:05:18PM +0100, Beno?t Th?baudeau wrote:
> Dear Sascha Hauer,
> 
> I've seen in the history of mxc_nand.c that you have worked on the
> nand_ecclayout structs. The following things look abnormal. Can you confirm?
>  - nandv1_hw_eccoob_smallpage and nandv2_hw_eccoob_smallpage:
>     * Why are bytes 0 and 1 in oobfree? These bytes are used for bad block
>       information on the 16-bit variants of these 512-byte-page NANDs.

This is probably a bug. Very few people seem to use 16bit flashes.

>  - nandv1_hw_eccoob_largepage:
>     * According to the i.MX31 reference manual, the BI bytes of the spare area
>       buffers are not free to use. So why are bytes 5, 11, 27, 43 and 59 in
>       oobfree? On the contrary, if this note is a mistake in the RM, then why
>       are bytes 21, 37 and 53 not in oobfree?
>  - nandv2_hw_eccoob_smallpage, nandv2_hw_eccoob_largepage and
>    nandv2_hw_eccoob_4k:
>     * Why is byte 6 not in oobfree?

Probably bugs aswell. Most people do not use filesystems requiring OOB
data anymore, so bugs may stay uncovered for longer.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

  reply	other threads:[~2012-11-21  9:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1214095427.1646097.1353358014121.JavaMail.root@advansee.com>
2012-11-20 20:05 ` mtd: nand: mxc: oobfree layout? Benoît Thébaudeau
2012-11-20 20:05   ` Benoît Thébaudeau
2012-11-21  9:25   ` Sascha Hauer [this message]
2012-11-21  9:25     ` Sascha Hauer

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=20121121092540.GP10369@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=benoit.thebaudeau@advansee.com \
    --cc=dwmw2@infradead.org \
    --cc=fabio.estevam@freescale.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=scottwood@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 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.