From: sashiko-bot@kernel.org
To: "James Hilliard" <james.hilliard1@gmail.com>,
"Miquel Raynal" <miquel.raynal@bootlin.com>,
"Richard Weinberger" <richard@nod.at>,
"Vignesh Raghavendra" <vigneshr@ti.com>,
"Sebastian Andrzej Siewior" <bigeasy@linutronix.de>,
"Clark Williams" <clrkwllms@kernel.org>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Philipp Zabel" <p.zabel@pengutronix.de>
Cc: "Chen-Yu Tsai" <wens@kernel.org>,
"Jernej Skrabec" <jernej.skrabec@gmail.com>,
"Samuel Holland" <samuel@sholland.org>,
"Maxime Ripard" <mripard@kernel.org>,
"Richard Genoud" <richard.genoud@bootlin.com>,
"Boris Brezillon" <bbrezillon@kernel.org>,
"Masahiro Yamada" <yamada.masahiro@socionext.com>,
"Brian Norris" <computersforpeace@gmail.com>,
linux-mtd@lists.infradead.org, linux-sunxi@lists.linux.dev,
linux-rt-devel@lists.linux.dev, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v10 01/26] mtd: rawnand: sunxi: centralize OOB handling
Date: Thu, 05 Nov 2026 19:13:20 +0000 [thread overview]
Message-ID: <sashiko-outbox-199823@kernel.org> (raw)
In-Reply-To: <20261105-submit-sunxi-nand-vendor-oob-layout-v1-v10-1-dca1f6ed29a8@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] mtd: rawnand: sunxi: premature oob_ops selection in sunxi_nand_attach_chip()
- [Medium] mtd: rawnand: sunxi: unaddressed maintainer NACK on vendor OOB layout ops
--
commit 8fda5c99d9befa1771418516828f040de60c5845
Author: James Hilliard <james.hilliard1@gmail.com>
mtd: rawnand: sunxi: centralize OOB handling
This commit centralizes hardware ECC result interpretation, protected OOB
retrieval, erased-chunk checking, and user-data layout reservation behind
per-chip sunxi_nfc_oob_ops callbacks for both PIO and DMA paths.
> diff --git a/drivers/mtd/nand/raw/sunxi_nand.c b/drivers/mtd/nand/raw/sunxi_nand.c
> index f41feebe42571..80006d1a33d68 100644
> --- a/drivers/mtd/nand/raw/sunxi_nand.c
> +++ b/drivers/mtd/nand/raw/sunxi_nand.c
[ ... ]
> @@ -2066,6 +2096,58 @@ static int sunxi_nfc_maximize_user_data(struct nand_chip *nand, uint32_t oobsize
[ ... ]
> +/*
> + * Both modes use the same layout and ECC policy. Scrambled transfers also
> + * compensate the first two user bytes to keep the on-flash BBM unmodified.
> + */
> +static const struct sunxi_nfc_oob_ops sunxi_nfc_plain_oob_ops = {
> + .min_user_data = sunxi_nfc_oob_min_user_data,
> + .init_user_data = sunxi_nfc_oob_init_user_data,
> + .read_batch = sunxi_nfc_oob_read_batch,
> + .finish_read = sunxi_nfc_oob_finish_read,
> +};
> +
> +static const struct sunxi_nfc_oob_ops sunxi_nfc_scrambled_plain_bbm_oob_ops = {
> + .min_user_data = sunxi_nfc_oob_min_user_data,
> + .init_user_data = sunxi_nfc_oob_init_user_data,
> + .transform_bbm = sunxi_nfc_randomize_bbm,
> + .read_batch = sunxi_nfc_oob_read_batch,
> + .finish_read = sunxi_nfc_oob_finish_read,
> +};
[Severity: Medium]
As reported by Miquel Raynal on v6 [1], the series adding support for the
vendor-specific Allwinner randomized OOB layout was declined due to
maintainability concerns and kernel policy against vendor-specific NAND
layouts, with an invitation to submit only the standalone fixes outside of
the randomized layout support.
Here, sunxi_nfc_plain_oob_ops and sunxi_nfc_scrambled_plain_bbm_oob_ops use
identical callbacks for min_user_data, init_user_data, read_batch, and
finish_read, differing only in transform_bbm. The remaining indirection in
struct sunxi_nfc_oob_ops is only used by the vendor-specific randomized OOB
layout patch later in the series.
Could the PIO and DMA ECC read helpers be shared directly and the standalone
fixes split out without introducing the struct sunxi_nfc_oob_ops vtable?
[ ... ]
> @@ -2254,6 +2303,9 @@ static int sunxi_nand_attach_chip(struct nand_chip *nand)
> if (!ecc->size || !ecc->strength)
> return -EINVAL;
>
> + sunxi_nand->oob_ops = nand->options & NAND_NEED_SCRAMBLING ?
> + &sunxi_nfc_scrambled_plain_bbm_oob_ops : &sunxi_nfc_plain_oob_ops;
[Severity: High]
Does selecting sunxi_nand->oob_ops in sunxi_nand_attach_chip() break bad
block marker compensation for chips that set NAND_NEED_SCRAMBLING during
nand_manufacturer_init()?
In nand_scan_with_ids(), nand_attach() runs before nand_scan_tail():
nand_scan_with_ids()
-> nand_scan_ident()
-> nand_attach()
-> sunxi_nand_attach_chip()
-> nand_scan_tail()
-> nand_manufacturer_init()
For ONFI-compliant chips where nand_onfi_detect() succeeds in nand_detect()
and jumps to ident_done without setting NAND_NEED_SCRAMBLING, the flag can
be set later in nand_manufacturer_init(), such as in
drivers/mtd/nand/raw/nand_toshiba.c:
toshiba_nand_init()
-> tc58teg5dclta00_init()
chip->options |= NAND_NEED_SCRAMBLING;
Because sunxi_nand_attach_chip() runs before nand_manufacturer_init(),
sunxi_nand->oob_ops is latched to sunxi_nfc_plain_oob_ops (where
transform_bbm is NULL). Later, during page and OOB reads and writes,
sunxi_nfc_randomizer_config() and sunxi_nfc_randomizer_enable() dynamically
check nand->options & NAND_NEED_SCRAMBLING and enable hardware scrambling,
while sunxi_nfc_hw_ecc_get_prot_oob_bytes() and
sunxi_nfc_hw_ecc_set_prot_oob_bytes() check sunxi_nand->oob_ops->transform_bbm
and skip calling sunxi_nfc_randomize_bbm().
[1] https://lore.kernel.org/r/871p9v4a1x.fsf@bootlin.com
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261105-submit-sunxi-nand-vendor-oob-layout-v1-v10-0-dca1f6ed29a8@gmail.com?part=1
next prev parent reply other threads:[~2026-11-05 19:13 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 18:55 [PATCH v10 00/26] mtd: rawnand: sunxi: fix transfers and support randomized OOB James Hilliard
2026-11-05 18:55 ` [PATCH v10 01/26] mtd: rawnand: sunxi: centralize OOB handling James Hilliard
2026-11-05 19:13 ` sashiko-bot [this message]
2026-11-05 18:55 ` [PATCH v10 02/26] mtd: rawnand: sunxi: share the buffer transfer chunk size James Hilliard
2026-11-05 18:55 ` [PATCH v10 03/26] mtd: rawnand: sunxi: avoid duplicate chip setup before page commands James Hilliard
2026-11-05 18:55 ` [PATCH v10 04/26] mtd: rawnand: sunxi: reject pages exceeding the ECC step limit James Hilliard
2026-11-05 18:55 ` [PATCH v10 05/26] mtd: rawnand: sunxi: use the logical step's OOB length in PIO James Hilliard
2026-11-05 18:55 ` [PATCH v10 06/26] mtd: rawnand: sunxi: propagate page-setup and erased-check errors James Hilliard
2026-11-05 18:55 ` [PATCH v10 07/26] mtd: rawnand: sunxi: drain interrupts before reusing the completion James Hilliard
2026-11-05 18:55 ` [PATCH v10 08/26] mtd: rawnand: sunxi: stop failed program operations and disable ECC James Hilliard
2026-11-05 18:55 ` [PATCH v10 09/26] mtd: rawnand: sunxi: select the pattern ID for the current ECC step James Hilliard
2026-11-05 18:55 ` [PATCH v10 10/26] mtd: rawnand: sunxi: preserve synthesized zero-pattern data and OOB James Hilliard
2026-11-05 18:55 ` [PATCH v10 11/26] mtd: rawnand: sunxi: propagate buffer and column transfer errors James Hilliard
2026-11-05 18:55 ` [PATCH v10 12/26] mtd: rawnand: sunxi: avoid a second program confirm for OOB writes James Hilliard
2026-11-05 18:55 ` [PATCH v10 13/26] mtd: rawnand: sunxi: use page reads to reposition small-page NAND James Hilliard
2026-11-05 18:55 ` [PATCH v10 14/26] mtd: rawnand: sunxi: bound DMA batches by the user-data register bank James Hilliard
2026-11-05 18:55 ` [PATCH v10 15/26] mtd: rawnand: sunxi: send all address cycles in split operations James Hilliard
2026-11-05 18:55 ` [PATCH v10 16/26] mtd: rawnand: sunxi: propagate chip clock setup errors James Hilliard
2026-11-05 18:55 ` [PATCH v10 17/26] mtd: rawnand: sunxi: limit buffer transfers to the command byte count James Hilliard
2026-11-05 18:55 ` [PATCH v10 18/26] mtd: rawnand: sunxi: skip unavailable NAND child nodes James Hilliard
2026-11-05 18:55 ` [PATCH v10 19/26] mtd: rawnand: sunxi: scan all chips before registering MTD devices James Hilliard
2026-11-05 18:55 ` [PATCH v10 20/26] dt-bindings: mtd: sunxi: require the H616 AHB reset James Hilliard
2026-11-05 18:55 ` [PATCH v10 21/26] mtd: rawnand: sunxi: reset the H616 data path after DMA aborts James Hilliard
2026-11-05 18:55 ` [PATCH v10 22/26] mtd: rawnand: sunxi: reuse ECC status within each transfer James Hilliard
2026-11-05 18:55 ` [PATCH v10 23/26] mtd: rawnand: sunxi: avoid redundant column changes for extra OOB James Hilliard
2026-11-05 18:55 ` [PATCH v10 24/26] mtd: rawnand: sunxi: reduce user-data length register accesses James Hilliard
2026-11-05 18:55 ` [PATCH v10 25/26] dt-bindings: mtd: sunxi: Add randomized OOB flag James Hilliard
2026-11-05 18:55 ` [PATCH v10 26/26] mtd: rawnand: sunxi: support the Allwinner randomized OOB format James Hilliard
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=sashiko-outbox-199823@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bbrezillon@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=clrkwllms@kernel.org \
--cc=computersforpeace@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=james.hilliard1@gmail.com \
--cc=jernej.skrabec@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=linux-sunxi@lists.linux.dev \
--cc=miquel.raynal@bootlin.com \
--cc=mripard@kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=richard.genoud@bootlin.com \
--cc=richard@nod.at \
--cc=robh@kernel.org \
--cc=rostedt@goodmis.org \
--cc=samuel@sholland.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vigneshr@ti.com \
--cc=wens@kernel.org \
--cc=yamada.masahiro@socionext.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