From: Christian Marangi <ansuelsmth@gmail.com>
To: "Rafał Miłecki" <rafal@milecki.pl>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Claudiu Beznea <claudiu.beznea@tuxon.dev>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v3] mtd: limit OTP NVMEM Cell parse to non Nand devices
Date: Thu, 28 Mar 2024 15:19:25 +0100 [thread overview]
Message-ID: <66057c71.050a0220.e4ba.97dc@mx.google.com> (raw)
In-Reply-To: <30bc0d38-b610-4397-ba42-46819d5507fc@milecki.pl>
On Wed, Mar 27, 2024 at 11:15:02PM +0100, Rafał Miłecki wrote:
> On 22.03.2024 05:09, Christian Marangi wrote:
> > 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;
>
> I think there may be even more unwanted behaviour here. If
> mtd_otp_nvmem_register() fails to find node with "user-otp" /
> "factory-otp" compatible then it sets "config.of_node" to NULL but that
> means NVMEM core still looks for NVMEM cells in device's "of_node".
>
> I believe we should not look for OTP NVMEM cells out of the "user-otp" /
> "factory-otp" compatible nodes.
>
> So maybe what we need in the first place is just:
> config.add_legacy_fixed_of_cells = !!np;
> ?
>
> Any extra limitation of .add_legacy_fixed_of_cells should probably be
> used only if we want to prevent new users of the legacy syntax. The
> problem is that mtd.yaml binding allowed "user-otp" and "factory-otp"
> with old syntax cells. It means every MTD device was allowed to have
> them.
>
> No in-kernel DTS even used "user-otp" or "factory-otp" with NVMEM legacy
> cells but I'm not sure about downstream DTS files. Ideally we would do
> config.add_legacy_fixed_of_cells = false;
> but that could break compatibility with some downstream DTS files.
Yes the main problem is prevent regression in downstream. I feel for the
nand usage, this is 100% of the times broken. For SPI and other corner
case MTD devices it's not?
Anyway did you by chance have a suggestion for a better fixes tag?
--
Ansuel
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Christian Marangi <ansuelsmth@gmail.com>
To: "Rafał Miłecki" <rafal@milecki.pl>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Claudiu Beznea <claudiu.beznea@tuxon.dev>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v3] mtd: limit OTP NVMEM Cell parse to non Nand devices
Date: Thu, 28 Mar 2024 15:19:25 +0100 [thread overview]
Message-ID: <66057c71.050a0220.e4ba.97dc@mx.google.com> (raw)
In-Reply-To: <30bc0d38-b610-4397-ba42-46819d5507fc@milecki.pl>
On Wed, Mar 27, 2024 at 11:15:02PM +0100, Rafał Miłecki wrote:
> On 22.03.2024 05:09, Christian Marangi wrote:
> > 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;
>
> I think there may be even more unwanted behaviour here. If
> mtd_otp_nvmem_register() fails to find node with "user-otp" /
> "factory-otp" compatible then it sets "config.of_node" to NULL but that
> means NVMEM core still looks for NVMEM cells in device's "of_node".
>
> I believe we should not look for OTP NVMEM cells out of the "user-otp" /
> "factory-otp" compatible nodes.
>
> So maybe what we need in the first place is just:
> config.add_legacy_fixed_of_cells = !!np;
> ?
>
> Any extra limitation of .add_legacy_fixed_of_cells should probably be
> used only if we want to prevent new users of the legacy syntax. The
> problem is that mtd.yaml binding allowed "user-otp" and "factory-otp"
> with old syntax cells. It means every MTD device was allowed to have
> them.
>
> No in-kernel DTS even used "user-otp" or "factory-otp" with NVMEM legacy
> cells but I'm not sure about downstream DTS files. Ideally we would do
> config.add_legacy_fixed_of_cells = false;
> but that could break compatibility with some downstream DTS files.
Yes the main problem is prevent regression in downstream. I feel for the
nand usage, this is 100% of the times broken. For SPI and other corner
case MTD devices it's not?
Anyway did you by chance have a suggestion for a better fixes tag?
--
Ansuel
next prev parent reply other threads:[~2024-03-28 14:19 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-22 4:09 [PATCH v3] mtd: limit OTP NVMEM Cell parse to non Nand devices Christian Marangi
2024-03-22 4:09 ` Christian Marangi
2024-03-25 10:18 ` Miquel Raynal
2024-03-25 10:18 ` Miquel Raynal
2024-03-27 14:26 ` Rafał Miłecki
2024-03-27 14:26 ` Rafał Miłecki
2024-03-27 14:36 ` Christian Marangi
2024-03-27 14:36 ` Christian Marangi
2024-03-27 15:31 ` Miquel Raynal
2024-03-27 15:31 ` Miquel Raynal
2024-03-28 14:20 ` Christian Marangi
2024-03-28 14:20 ` Christian Marangi
2024-03-27 21:53 ` Rafał Miłecki
2024-03-27 21:53 ` Rafał Miłecki
2024-03-27 22:15 ` Rafał Miłecki
2024-03-27 22:15 ` Rafał Miłecki
2024-03-28 14:19 ` Christian Marangi [this message]
2024-03-28 14:19 ` Christian Marangi
2024-03-28 14:44 ` Rafał Miłecki
2024-03-28 14:44 ` Rafał Miłecki
2024-03-30 9:13 ` Christian Marangi
2024-03-30 9:13 ` Christian Marangi
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=66057c71.050a0220.e4ba.97dc@mx.google.com \
--to=ansuelsmth@gmail.com \
--cc=claudiu.beznea@tuxon.dev \
--cc=gregkh@linuxfoundation.org \
--cc=jernej.skrabec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=rafal@milecki.pl \
--cc=richard@nod.at \
--cc=srinivas.kandagatla@linaro.org \
--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.