From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Cheng Ming Lin <linchengming884@gmail.com>
Cc: richard@nod.at, vigneshr@ti.com, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org,
tudor.ambarus@linaro.org, mmkurbanov@salutedevices.com,
Takahiro.Kuwano@infineon.com, pratyush@kernel.org,
linux-mtd@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, alvinzhou@mxic.com.tw,
Cheng Ming Lin <chengminglin@mxic.com.tw>
Subject: Re: [PATCH v2 1/3] dt-bindings: mtd: spi-nand: Add enable-randomizer-otp property
Date: Wed, 10 Sep 2025 11:09:35 +0200 [thread overview]
Message-ID: <87wm66d67k.fsf@bootlin.com> (raw)
In-Reply-To: <20250910030301.1368372-2-linchengming884@gmail.com> (Cheng Ming Lin's message of "Wed, 10 Sep 2025 11:02:59 +0800")
Hello Cheng Ming,
On 10/09/2025 at 11:02:59 +08, Cheng Ming Lin <linchengming884@gmail.com> wrote:
> From: Cheng Ming Lin <chengminglin@mxic.com.tw>
>
> Add a new boolean property "enable-randomizer-otp" to enable the
> randomizer feature on supported SPI-NAND devices.
>
> Signed-off-by: Cheng Ming Lin <chengminglin@mxic.com.tw>
> ---
> Documentation/devicetree/bindings/mtd/spi-nand.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mtd/spi-nand.yaml b/Documentation/devicetree/bindings/mtd/spi-nand.yaml
> index 77a8727c7..432bc79e9 100644
> --- a/Documentation/devicetree/bindings/mtd/spi-nand.yaml
> +++ b/Documentation/devicetree/bindings/mtd/spi-nand.yaml
> @@ -21,6 +21,10 @@ properties:
> description: Encode the chip-select line on the SPI bus
> maxItems: 1
>
> + enable-randomizer-otp:
This is a NAND wide feature, so we should probably add a prefix, such as
"nand,".
Now, what about this "otp" suffix? Many (if not all) chips have a
volatile setting for that. About the naming, "otp" often reflects to the
OTP area, which is not what you imply here, as you want to insist
(rightfully) on the fact that this feature cannot be disabled.
Also, this is a per-chip configuration, while I would have welcomed a
per-partition configuration. I can easily imagine two cases:
- The boot ROM, for longevity purposes, expects the first blocks
containing the bootloader to be scrambled. However the rest of the
system does not really care and disables randomization.
- The boot ROM is not capable of de-scrambling, however the rest of the
system relies on the (probably) more robust scrambling feature.
In both cases a chip wide variable is not relevant.
The fact that it is a one-time feature makes it even harder to fit into
something generic.
How do you think these constraints could fit with your needs? Can you
please explain again (sorry for the repetition) what Macronix chips have
the volatile capability and which ones do not?
Thanks,
Miquèl
next prev parent reply other threads:[~2025-09-10 9:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-10 3:02 [PATCH v2 0/3] mtd: spi-nand: Add support for randomizer Cheng Ming Lin
2025-09-10 3:02 ` [PATCH v2 1/3] dt-bindings: mtd: spi-nand: Add enable-randomizer-otp property Cheng Ming Lin
2025-09-10 9:09 ` Miquel Raynal [this message]
2025-09-10 16:36 ` Rob Herring
2025-09-11 7:08 ` Miquel Raynal
2025-09-11 7:24 ` Cheng Ming Lin
2025-09-11 7:59 ` Miquel Raynal
2025-09-11 8:30 ` Cheng Ming Lin
2025-09-11 13:56 ` Miquel Raynal
2025-09-12 7:50 ` Cheng Ming Lin
2025-09-10 11:40 ` Krzysztof Kozlowski
2025-09-11 8:05 ` Cheng Ming Lin
2025-09-10 3:03 ` [PATCH v2 2/3] mtd: spi-nand: Add support for randomizer Cheng Ming Lin
2025-09-10 3:03 ` [PATCH v2 3/3] mtd: spi-nand: macronix: Add randomizer support Cheng Ming Lin
2025-09-10 9:12 ` Miquel Raynal
2025-09-10 9:26 ` Cheng Ming Lin
2025-09-10 9:43 ` Miquel Raynal
2025-09-11 5:15 ` Cheng Ming Lin
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=87wm66d67k.fsf@bootlin.com \
--to=miquel.raynal@bootlin.com \
--cc=Takahiro.Kuwano@infineon.com \
--cc=alvinzhou@mxic.com.tw \
--cc=chengminglin@mxic.com.tw \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linchengming884@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=mmkurbanov@salutedevices.com \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=robh@kernel.org \
--cc=tudor.ambarus@linaro.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;
as well as URLs for NNTP newsgroup(s).