[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAyq3SbXiPUjZE7OCAe1=uw4h82bFN7DSU4bLx1dhKe_XFtu=w@mail.gmail.com>
Date: Thu, 11 Sep 2025 15:24:35 +0800
From: Cheng Ming Lin <linchengming884@...il.com>
To: Miquel Raynal <miquel.raynal@...tlin.com>
Cc: richard@....at, vigneshr@...com, robh@...nel.org, krzk+dt@...nel.org,
conor+dt@...nel.org, tudor.ambarus@...aro.org, mmkurbanov@...utedevices.com,
Takahiro.Kuwano@...ineon.com, pratyush@...nel.org,
linux-mtd@...ts.infradead.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, alvinzhou@...c.com.tw,
Cheng Ming Lin <chengminglin@...c.com.tw>
Subject: Re: [PATCH v2 1/3] dt-bindings: mtd: spi-nand: Add
enable-randomizer-otp property
Hi Miquel,
Miquel Raynal <miquel.raynal@...tlin.com> 於 2025年9月10日 週三 下午5:10寫道:
>
> Hello Cheng Ming,
>
> On 10/09/2025 at 11:02:59 +08, Cheng Ming Lin <linchengming884@...il.com> wrote:
>
> > From: Cheng Ming Lin <chengminglin@...c.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@...c.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.
Yes, my intention is that once the randomizer feature is enabled, it
should not be disabled again. You are correct that this bit does not
belong to the OTP area, but rather to the v2 volatile register. The v2
volatile register has a default value that can be changed through a
special OTP configuration register program operation. Regarding the
"otp" suffix, I will remove it to avoid misunderstanding.
>
> 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 scrambling and descrambling are handled by the NAND flash hardware
itself. Therefore, the boot ROM does not need to support a descrambling
feature.
In the case of Macronix parts, the randomizer is controlled through a
configuration register, and once it is enabled it covers the entire chip
(main and/or spare depending on the randopt bit). There is no hardware
mechanism to enable it only on certain ranges.
>
> The fact that it is a one-time feature makes it even harder to fit into
> something generic.
>
This isn't a true one-time programming feature. Its default value can be
changed through a specific procedure.
Please refer to page 29 and page 51 of the datasheet for specific
procedure and details.
Link: https://www.mxic.com.tw/Lists/Datasheet/Attachments/9036/MX35LF4G24AD,%203V,%204Gb,%20v1.4.pdf
> 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?
Macronix chips that support the randomizer feature are V2 type registers.
>
> Thanks,
> Miquèl
Thanks,
Cheng Ming Lin
Powered by blists - more mailing lists