All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Richard Genoud <richard.genoud@bootlin.com>
Cc: Richard Weinberger <richard@nod.at>,
	 Vignesh Raghavendra <vigneshr@ti.com>,
	 Chen-Yu Tsai <wens@csie.org>,
	 Jernej Skrabec <jernej.skrabec@gmail.com>,
	 Samuel Holland <samuel@sholland.org>,
	 Wentao Liang <vulab@iscas.ac.cn>,
	 Maxime Ripard <mripard@kernel.org>,
	 Boris Brezillon <bbrezillon@kernel.org>,
	 Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	 linux-mtd@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	 linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 6/6] mtd: rawnand: sunxi: introduce variable user data length
Date: Thu, 12 Mar 2026 15:41:37 +0100	[thread overview]
Message-ID: <87a4wdkt3y.fsf@bootlin.com> (raw)
In-Reply-To: <20260305100137.2558423-7-richard.genoud@bootlin.com> (Richard Genoud's message of "Thu, 5 Mar 2026 11:01:37 +0100")

Hello Richard,

On 05/03/2026 at 11:01:37 +01, Richard Genoud <richard.genoud@bootlin.com> wrote:

> In Allwinner SoCs, user data can be added in OOB before each ECC data.
> For older SoCs like A10, the user data size was the size of a register
> (4 bytes) and was mandatory before each ECC step.
> So, the A10 OOB Layout is:
> [4Bytes USER_DATA_STEP0] [ECC_STEP0 bytes]
> [4bytes USER_DATA_STEP1] [ECC_STEP1 bytes]
> ...
> NB: the BBM is stored at the beginning of the USER_DATA_STEP0.
>
> Now, for H6/H616 NAND flash controller, this user data can have a
> different size for each step.
> And the vendor has chosen a different layout from the one on A10, using
> 8 bytes for step 0 and nothing for further steps:
> [8bytes USER_DATA_STEP0] [ECC_STEP0 bytes] [ECC_STEP1 bytes]...
> (Still with BBM stored at the beginning of the USER_DATA_STEP0)

I would rather be in favour of not following $(random vendor) firmware
layout. Upstream, it makes probably more sense to just allow access to
the maximum number of bytes that can be covered by the ECC engine, so I
would rather be in favour of computing the maximum size that you can set
for each step, without going over the OOB size.

Once this set up, I believe adapting the driver locally (out of tree) to
match a specific vendor layout would be rather straightforward, as all
the configuration pieces would already be in place.

Thanks,
Miquèl


WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Richard Genoud <richard.genoud@bootlin.com>
Cc: Richard Weinberger <richard@nod.at>,
	 Vignesh Raghavendra <vigneshr@ti.com>,
	 Chen-Yu Tsai <wens@csie.org>,
	 Jernej Skrabec <jernej.skrabec@gmail.com>,
	 Samuel Holland <samuel@sholland.org>,
	 Wentao Liang <vulab@iscas.ac.cn>,
	 Maxime Ripard <mripard@kernel.org>,
	 Boris Brezillon <bbrezillon@kernel.org>,
	 Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	 linux-mtd@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	 linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 6/6] mtd: rawnand: sunxi: introduce variable user data length
Date: Thu, 12 Mar 2026 15:41:37 +0100	[thread overview]
Message-ID: <87a4wdkt3y.fsf@bootlin.com> (raw)
In-Reply-To: <20260305100137.2558423-7-richard.genoud@bootlin.com> (Richard Genoud's message of "Thu, 5 Mar 2026 11:01:37 +0100")

Hello Richard,

On 05/03/2026 at 11:01:37 +01, Richard Genoud <richard.genoud@bootlin.com> wrote:

> In Allwinner SoCs, user data can be added in OOB before each ECC data.
> For older SoCs like A10, the user data size was the size of a register
> (4 bytes) and was mandatory before each ECC step.
> So, the A10 OOB Layout is:
> [4Bytes USER_DATA_STEP0] [ECC_STEP0 bytes]
> [4bytes USER_DATA_STEP1] [ECC_STEP1 bytes]
> ...
> NB: the BBM is stored at the beginning of the USER_DATA_STEP0.
>
> Now, for H6/H616 NAND flash controller, this user data can have a
> different size for each step.
> And the vendor has chosen a different layout from the one on A10, using
> 8 bytes for step 0 and nothing for further steps:
> [8bytes USER_DATA_STEP0] [ECC_STEP0 bytes] [ECC_STEP1 bytes]...
> (Still with BBM stored at the beginning of the USER_DATA_STEP0)

I would rather be in favour of not following $(random vendor) firmware
layout. Upstream, it makes probably more sense to just allow access to
the maximum number of bytes that can be covered by the ECC engine, so I
would rather be in favour of computing the maximum size that you can set
for each step, without going over the OOB size.

Once this set up, I believe adapting the driver locally (out of tree) to
match a specific vendor layout would be rather straightforward, as all
the configuration pieces would already be in place.

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2026-03-12 14:42 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-05 10:01 [PATCH v2 0/6] mtd: rawnand: sunxi: Fixes user data length for H6 Richard Genoud
2026-03-05 10:01 ` Richard Genoud
2026-03-05 10:01 ` [PATCH v2 1/6] mtd: rawnand: sunxi: sunxi_nand_ooblayout_free code clarification Richard Genoud
2026-03-05 10:01   ` Richard Genoud
2026-03-14  8:05   ` Chen-Yu Tsai
2026-03-14  8:05     ` Chen-Yu Tsai
2026-03-05 10:01 ` [PATCH v2 2/6] mtd: rawnand: sunxi: fix sunxi_nfc_hw_ecc_read_extra_oob Richard Genoud
2026-03-05 10:01   ` Richard Genoud
2026-03-05 10:01 ` [PATCH v2 3/6] mtd: rawnand: sunxi: do not count BBM bytes twice Richard Genoud
2026-03-05 10:01   ` Richard Genoud
2026-03-09 15:27   ` Miquel Raynal
2026-03-09 15:27     ` Miquel Raynal
2026-03-12 10:39     ` Richard GENOUD
2026-03-12 10:39       ` Richard GENOUD
2026-03-05 10:01 ` [PATCH v2 4/6] mtd: rawnand: sunxi: replace hard coded value by a define - take2 Richard Genoud
2026-03-05 10:01   ` Richard Genoud
2026-03-05 10:01 ` [PATCH v2 5/6] mtd: rawnand: sunxi: make the code mode self-explanatory Richard Genoud
2026-03-05 10:01   ` Richard Genoud
2026-03-09 16:50   ` Miquel Raynal
2026-03-09 16:50     ` Miquel Raynal
2026-03-12 10:47     ` Richard GENOUD
2026-03-12 10:47       ` Richard GENOUD
2026-03-05 10:01 ` [PATCH v2 6/6] mtd: rawnand: sunxi: introduce variable user data length Richard Genoud
2026-03-05 10:01   ` Richard Genoud
2026-03-12 14:41   ` Miquel Raynal [this message]
2026-03-12 14:41     ` Miquel Raynal
2026-03-13 13:17     ` Richard GENOUD
2026-03-13 13:17       ` Richard GENOUD

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=87a4wdkt3y.fsf@bootlin.com \
    --to=miquel.raynal@bootlin.com \
    --cc=bbrezillon@kernel.org \
    --cc=jernej.skrabec@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=mripard@kernel.org \
    --cc=richard.genoud@bootlin.com \
    --cc=richard@nod.at \
    --cc=samuel@sholland.org \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=vigneshr@ti.com \
    --cc=vulab@iscas.ac.cn \
    --cc=wens@csie.org \
    /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.