From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Christian Marangi <ansuelsmth@gmail.com>
Cc: "Rafał Miłecki" <rafal@milecki.pl>,
"Richard Weinberger" <richard@nod.at>,
"Vignesh Raghavendra" <vigneshr@ti.com>,
"Michael Walle" <michael@walle.cc>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v4] mtd: limit OTP NVMEM Cell parse to non Nand devices
Date: Mon, 8 Apr 2024 15:12:56 +0200 [thread overview]
Message-ID: <20240408151256.11d4e69c@xps-13> (raw)
In-Reply-To: <20240402212331.27328-1-ansuelsmth@gmail.com>
Hi Christian,
ansuelsmth@gmail.com wrote on Tue, 2 Apr 2024 23:23:19 +0200:
> MTD OTP logic is very fragile on parsing NVMEM Cell and can be
> problematic with some specific kind of devices.
>
> The problem was discovered by e87161321a40 ("mtd: rawnand: macronix:
> OTP access for MX30LFxG18AC") where OTP support was added to a NAND
> device. With the case of NAND devices, it does require a node where ECC
> info are declared and all the fixed partitions, and this cause the OTP
> codepath to parse this node as OTP NVMEM Cells, making probe fail and
> the NAND device registration fail.
>
> MTD OTP parsing should have been limited to always using compatible to
> prevent this error by using node with compatible "otp-user" or
> "otp-factory".
>
> NVMEM across the years had various iteration on how Cells could be
> declared in DT, in some old implementation, no_of_node should have been
> enabled but now add_legacy_fixed_of_cells should be used to disable
> NVMEM to parse child node as NVMEM Cell.
>
> To fix this and limit any regression with other MTD that makes use of
> declaring OTP as direct child of the dev node, disable
> add_legacy_fixed_of_cells if we detect the MTD type is Nand.
>
> With the following logic, the OTP NVMEM entry is correctly created with
> no Cells and the MTD Nand is correctly probed and partitions are
> correctly exposed.
>
> Fixes: 4b361cfa8624 ("mtd: core: add OTP nvmem provider support")
> Cc: <stable@vger.kernel.org> # v6.7+
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Feels okay to me, but I'd like to get validation from Rafał as well who
extensively worked on this aspect and must have a sharpened eyed for
this kind of issue :-)
> ---
>
> To backport this to v6.6 and previous,
>
> config.no_of_node = mtd_type_is_nand(mtd);
>
> should be used as it does pose the same usage of
> add_legacy_fixed_of_cells.
>
> Changes v4:
> - Add info on how to backport this to previous kernel
> - Fix Fixes tag
> - Reformat commit description as it was unprecise and
> had false statement
> Changes v3:
> - Fix commit description
> Changes v2:
> - Use mtd_type_is_nand instead of node name check
>
> drivers/mtd/mtdcore.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index 5887feb347a4..0de87bc63840 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c
> @@ -900,7 +900,7 @@ static struct nvmem_device
> *mtd_otp_nvmem_register(struct mtd_info *mtd, config.name =
> compatible; config.id = NVMEM_DEVID_AUTO;
> config.owner = THIS_MODULE;
> - config.add_legacy_fixed_of_cells = true;
> + config.add_legacy_fixed_of_cells = !mtd_type_is_nand(mtd);
> config.type = NVMEM_TYPE_OTP;
> config.root_only = true;
> config.ignore_wp = true;
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2024-04-08 13:13 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-02 21:23 [PATCH v4] mtd: limit OTP NVMEM Cell parse to non Nand devices Christian Marangi
2024-04-08 13:12 ` Miquel Raynal [this message]
2024-04-09 9:41 ` Michael Walle
2024-04-12 7:23 ` Miquel Raynal
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=20240408151256.11d4e69c@xps-13 \
--to=miquel.raynal@bootlin.com \
--cc=ansuelsmth@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=michael@walle.cc \
--cc=rafal@milecki.pl \
--cc=richard@nod.at \
--cc=stable@vger.kernel.org \
--cc=vigneshr@ti.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