Message-ID: <CAAyq3SaiVyh9Sr_Qj9h8kQ0ZRRVHjk=VRV5sHueeYjNmz2UW3Q@mail.gmail.com>
Date: Fri, 12 Sep 2025 15:50:09 +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月11日 週四 下午9:57寫道：
>
> Hi,
>
> >> >> 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.
> >>
> >> I believe the motivation behind this choice is incorrect and does not
> >> fit such an OS as Linux. We want to give the system administrator the
> >> choice to select and unselect features as it sees fit. So if there is a
> >> volatile way to enable something, we should go for it and we will pay
> >> the extra penalty of a set_feature() (or whatever) command after each
> >> boot. Making this type of change permanent makes development and
> >> debugging much more painful. There are plenty of configurations that we
> >> refuse to apply with non volatile configurations. In general, stateful
> >> modes are problematic if they are kept after a reboot and we try our
> >> best to avoid them.
> >>
> >> Once this feature is enabled, for the lifetime of "a product", it does
> >> not make sense to disable it indeed. And the DT must remain correct, if
> >> it is changed in a non compatible way, that's the administrator
> >> responsibility.
> >>
> >> So are there ways to enable this feature in a way that returns to the
> >> default state after a reset?
> >
> > Thank you for the detailed feedback. I understand and agree with the
> > principle of favoring volatile configurations to give administrators
> > more control and simplify debugging.
> >
> > Yes, it is possible to enable this feature in a way that it returns
> > to the default state after a reset.
> >
> > We can use the standard set_feature command to set the RANDEN bit to 1,
> > which enables the randomizer. This configuration is volatile and will
> > not persist through a power cycle. The feature will remain disabled by
> > default on each boot unless it is explicitly enabled again.
> >
> > I will update the patch to implement this volatile approach.
>
> I would be in favour of implementing this method. Hence, no more OTP
> constraint to express in the binding either.

I wonder if we could still go with two approaches.

For Macronix we may add a DT property in macronix.c to decide whether
to use a set feature operation or the special OTP program operations.

>
> >> > 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.
> >>
> >> After thinking once again, I am no longer aligned with myself from the
> >> past. This is perhaps too Macronix specific in the end and if it is a
> >> fully transparent feature, then why not.
> >>
> >> Are there any ways we can read the raw data (unscrambled) once
> >> scrambling has been enabled? (I mean, without changing the user default
> >> OTP state). Maybe one big difference with the raw NAND world that needs
> >> to be taken into account is that the chip itself always return
> >> unscrambled data, hence we probably do not care much, from a Linux
> >> perspective.
> >
> > Unfortunately, there is no way to do this. If a user decides to use the
> > randomizer feature, they must enable it before programming the user OTP
> > area. If the randomizer is not enabled before the user OTP is programmed,
> > any subsequent reads will result in corrupted data.
> >
> > Marconix raw NAND chip itself does not always return unscrambled data.
> >
> > The ability to read unscrambled data is dependent on whether the
> > randomizer feature was enabled and configured correctly. When the
> > randomizer is turned on, the chip's internal hardware automatically
> > handles the unscrambling process. If the feature is not enabled, the
> > data read from the memory will be the raw, scrambled information, which
> > is unusable without the correct key and algorithm. In other words, the
> > chip only returns unscrambled data if randomizer feature is enabled.
>
> That is interesting and might be useful. In Linux we will enable the
> scrambler if the data property is enabled before we get to play with the
> OTP anyway, so hopefully people will get it right.
>
> Regarding the property name, it is going to be a per SPI NAND chip
> property. I am still not sure whether we should make this prop generic
> or not. Perhaps the safest approach is to keep it vendor specific, but
> the concept of scrambling internal data for longevity purposes is common
> enough to deserve a nand- prefix. Although it's gonna be like ECC
> engines, we'll need to decide which part of the system handles the
> scrambling (software, hardware on host or chip itself) and whether it is
> enabled per-chip or per-partition when that's possible.
>
> I am open to suggestions.

I also think we may consider moving the randomizer support into the NAND
layer, not just SPI-NAND, since Macronix ONFI NAND devices also support
randomizer. And I agree it would be similar to ECC engines, where the
scrambling of data can be determined by software, hardware on the host,
or by the chip itself.

>
> Thanks,
> Miquèl

Thanks,
Cheng Ming Lin

Powered by blists - more mailing lists