Message-ID: <87wm659jol.fsf@bootlin.com>
Date: Thu, 11 Sep 2025 15:56:42 +0200
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Cheng Ming Lin <linchengming884@...il.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,

>> >> 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.

>> > 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.

Thanks,
Miquèl

Powered by blists - more mailing lists