All of lore.kernel.org
 help / color / mirror / Atom feed
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/

WARNING: multiple messages have this Message-ID (diff)
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

  reply	other threads:[~2024-04-08 13:13 UTC|newest]

Thread overview: 8+ 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-02 21:23 ` Christian Marangi
2024-04-08 13:12 ` Miquel Raynal [this message]
2024-04-08 13:12   ` Miquel Raynal
2024-04-09  9:41 ` Michael Walle
2024-04-09  9:41   ` Michael Walle
2024-04-12  7:23   ` Miquel Raynal
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 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.