[PATCH v2 0/3] mtd: spi-nand: Add support for randomizer

[PATCH v2 0/3] mtd: spi-nand: Add support for randomizer

[Cheng Ming Lin]

From: Cheng Ming Lin <chengminglin@mxic.com.tw>

Introduce randomizer feature for SPI-NAND devices.

Add a new DT property named "enable-randomizer-otp" to enable the
randomizer feature.

v2:
* Create a global NAND DT property

Cheng Ming Lin (3):
  dt-bindings: mtd: spi-nand: Add enable-randomizer-otp property
  mtd: spi-nand: Add support for randomizer
  mtd: spi-nand: macronix: Add randomizer support

 .../devicetree/bindings/mtd/spi-nand.yaml     |  4 +
 drivers/mtd/nand/spi/core.c                   | 24 +++++
 drivers/mtd/nand/spi/macronix.c               | 89 ++++++++++++++++---
 include/linux/mtd/spinand.h                   |  7 ++
 4 files changed, 114 insertions(+), 10 deletions(-)

-- 
2.25.1

[PATCH v2 1/3] dt-bindings: mtd: spi-nand: Add enable-randomizer-otp property

[Cheng Ming Lin]

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:
+    description: Enable the randomizer feature
+    type: boolean
+
 required:
   - compatible
   - reg
-- 
2.25.1

Re: [PATCH v2 1/3] dt-bindings: mtd: spi-nand: Add enable-randomizer-otp property

[Miquel Raynal]

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

Re: [PATCH v2 1/3] dt-bindings: mtd: spi-nand: Add enable-randomizer-otp property

[Rob Herring]

On Wed, Sep 10, 2025 at 11:09:35AM +0200, Miquel Raynal wrote:
> 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,".

'nand' is not a vendor, so no.

Rob

Re: [PATCH v2 1/3] dt-bindings: mtd: spi-nand: Add enable-randomizer-otp property

[Miquel Raynal]

Hi,

On 10/09/2025 at 11:36:31 -05, Rob Herring <robh@kernel.org> wrote:

> On Wed, Sep 10, 2025 at 11:09:35AM +0200, Miquel Raynal wrote:
>> 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,".
>
> 'nand' is not a vendor, so no.

Sorry for the confusion I meant "nand-", like we already have:
- nand-ecc-engine
- nand-use-soft-ecc-engine
- nand-ecc-strength
- nand-ecc-step-size
etc

Thanks,
Miquèl

Re: [PATCH v2 1/3] dt-bindings: mtd: spi-nand: Add enable-randomizer-otp property

[Cheng Ming Lin]

Hi Miquel,

Miquel Raynal <miquel.raynal@bootlin.com> 於 2025年9月10日 週三 下午5:10寫道：
>
> 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.

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

Re: [PATCH v2 1/3] dt-bindings: mtd: spi-nand: Add enable-randomizer-otp property

[Miquel Raynal]

Hi Cheng Ming,

On 11/09/2025 at 15:24:35 +08, Cheng Ming Lin <linchengming884@gmail.com> wrote:

> Hi Miquel,
>
> Miquel Raynal <miquel.raynal@bootlin.com> 於 2025年9月10日 週三 下午5:10寫道：
>>
>> 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.
>
> 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?

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

Thanks,
Miquèl

Re: [PATCH v2 1/3] dt-bindings: mtd: spi-nand: Add enable-randomizer-otp property

[Cheng Ming Lin]

Hi Miquel,

Miquel Raynal <miquel.raynal@bootlin.com> 於 2025年9月11日 週四 下午3:59寫道：
>
> Hi Cheng Ming,
>
> On 11/09/2025 at 15:24:35 +08, Cheng Ming Lin <linchengming884@gmail.com> wrote:
>
> > Hi Miquel,
> >
> > Miquel Raynal <miquel.raynal@bootlin.com> 於 2025年9月10日 週三 下午5:10寫道：
> >>
> >> 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.
> >
> > 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.

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

>
> Thanks,
> Miquèl

Thanks,
Cheng Ming Lin

Re: [PATCH v2 1/3] dt-bindings: mtd: spi-nand: Add enable-randomizer-otp property

[Miquel Raynal]

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

Re: [PATCH v2 1/3] dt-bindings: mtd: spi-nand: Add enable-randomizer-otp property

[Cheng Ming Lin]

Hi Miquel,

Miquel Raynal <miquel.raynal@bootlin.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

Re: [PATCH v2 1/3] dt-bindings: mtd: spi-nand: Add enable-randomizer-otp property

[Krzysztof Kozlowski]

On Wed, Sep 10, 2025 at 11:02:59AM +0800, Cheng Ming Lin 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.

What is randomizer feature? Subject, commit msg, description - none of
them explain me that. Is this some standard for NAND? Why is this a
common property?

So many questions and zero explanations in the commit msg. Instead you
just wrote what we see in the diff - that's completely redundant.

Best regards,
Krzysztof

Re: [PATCH v2 1/3] dt-bindings: mtd: spi-nand: Add enable-randomizer-otp property

[Cheng Ming Lin]

Hi Krzysztof,

Krzysztof Kozlowski <krzk@kernel.org> 於 2025年9月10日 週三 下午7:40寫道：
>
> On Wed, Sep 10, 2025 at 11:02:59AM +0800, Cheng Ming Lin 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.
>
> What is randomizer feature? Subject, commit msg, description - none of
> them explain me that. Is this some standard for NAND? Why is this a
> common property?

To the best of our knowledge, Macronix was the first vendor to
implement this feature in hardware to enhance data reliability and
endurance, especially under high P/E cycle stress.

Since this is a vendor-specific implementation rather than a common
NAND standard, I agree that this property should be handled within
the Marconix driver specifically, not as a common property. I will
make the necessary adjustments.

>
> So many questions and zero explanations in the commit msg. Instead you
> just wrote what we see in the diff - that's completely redundant.

Thank you for your feedback. I apologize that the commit message was not
clear and did not provide sufficient context for this feature.
Your questions are very valid and I should have included these details from
the beginning.

According to JEDEC standard JESD22-A117E, no single data pattern
represents a universal worst-case for all NAND flash failure mechanisms.
Different patterns, such as fully programmed, checkerboard, or mostly
erased, can disproportionately stress specific cells (e.g., programmed,
erased, or those influenced by adjacent states).

Given that no fixed pattern can cover all scenarios, the use of a
randomized data pattern is a practical and effective mitigation strategy.
Our hardware implements a randomizer feature that scrambles user data
before it is written to the flash and restores the original data upon read.

This ensures the data stored on the media is more evenly distributed,
thus reducing pattern-dependent degradation. This is especially crucial
for preventing errors caused by unbalanced data (e.g., all zeros or
all ones) in blocks with high program/erase (P/E) cycle counts.
Ultimately, the randomizer improves the long-term reliability and
endurance of the flash device.

Please refer to the following link for randomizer feature:
Link: https://www.mxic.com.tw/Lists/ApplicationNote/Attachments/2151/AN1051V1-The%20Introduction%20of%20Randomizer%20Feature%20on%20MX30xFxG28AD_MX35xFxG24AD.pdf

>
> Best regards,
> Krzysztof
>

Best regards,
Cheng Ming Lin

[PATCH v2 2/3] mtd: spi-nand: Add support for randomizer

[Cheng Ming Lin]

From: Cheng Ming Lin <chengminglin@mxic.com.tw>

Introduce randomizer initialization for SPI-NAND devices.

According to JESD22-A117E, there is no single data pattern that represents
a universal worst-case across all failure mechanisms. Different mechanisms
may stress programmed cells, erased cells, or cells influenced by adjacent
states, and thus specific patterns such as fully programmed, checkerboard,
or mostly erased are each only worst-case for certain desings or processes.

Given that no fixed pattern can cover all cases, the use of a randomized
data pattern is considered a practical mitigation strategy. A randomizer
distributes stress more evenly across the device by scrambling incoming
data before storage and restoring it on read. This helps reduce
pattern-dependent degradation and can therefore improve flash reliability.

Signed-off-by: Cheng Ming Lin <chengminglin@mxic.com.tw>
---
 drivers/mtd/nand/spi/core.c | 24 ++++++++++++++++++++++++
 include/linux/mtd/spinand.h |  7 +++++++
 2 files changed, 31 insertions(+)

diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index ea47028d0..770304403 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -854,6 +854,25 @@ static void spinand_cont_read_init(struct spinand_device *spinand)
 	}
 }
 
+static int spinand_randomizer_init(struct spinand_device *spinand)
+{
+	struct nand_device *nand = spinand_to_nand(spinand);
+	struct device_node *dn = nanddev_get_of_node(nand);
+	int ret, rand_dt;
+
+	rand_dt = of_property_read_bool(dn, "enable-randomizer-otp");
+	if (!rand_dt)
+		return 0;
+
+	if (spinand->set_randomizer) {
+		ret = spinand->set_randomizer(spinand);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
 static bool spinand_use_cont_read(struct mtd_info *mtd, loff_t from,
 				  struct mtd_oob_ops *ops)
 {
@@ -1367,6 +1386,7 @@ int spinand_match_and_init(struct spinand_device *spinand,
 		spinand->user_otp = &table[i].user_otp;
 		spinand->read_retries = table[i].read_retries;
 		spinand->set_read_retry = table[i].set_read_retry;
+		spinand->set_randomizer = table[i].set_randomizer;
 
 		op = spinand_select_op_variant(spinand,
 					       info->op_variants.read_cache);
@@ -1544,6 +1564,10 @@ static int spinand_init(struct spinand_device *spinand)
 	 */
 	spinand_cont_read_init(spinand);
 
+	ret = spinand_randomizer_init(spinand);
+	if (ret)
+		goto err_cleanup_ecc_engine;
+
 	mtd->_read_oob = spinand_mtd_read;
 	mtd->_write_oob = spinand_mtd_write;
 	mtd->_block_isbad = spinand_mtd_block_isbad;
diff --git a/include/linux/mtd/spinand.h b/include/linux/mtd/spinand.h
index 927c10d78..66ea8eed4 100644
--- a/include/linux/mtd/spinand.h
+++ b/include/linux/mtd/spinand.h
@@ -500,6 +500,7 @@ struct spinand_user_otp {
  * @user_otp: SPI NAND user OTP info.
  * @read_retries: the number of read retry modes supported
  * @set_read_retry: enable/disable read retry for data recovery
+ * @set_randomizer: enable randomizer
  *
  * Each SPI NAND manufacturer driver should have a spinand_info table
  * describing all the chips supported by the driver.
@@ -521,6 +522,7 @@ struct spinand_info {
 	int (*configure_chip)(struct spinand_device *spinand);
 	int (*set_cont_read)(struct spinand_device *spinand,
 			     bool enable);
+	int (*set_randomizer)(struct spinand_device *spinand);
 	struct spinand_fact_otp fact_otp;
 	struct spinand_user_otp user_otp;
 	unsigned int read_retries;
@@ -579,6 +581,9 @@ struct spinand_info {
 	.read_retries = __read_retries,					\
 	.set_read_retry = __set_read_retry
 
+#define SPINAND_RANDOMIZER(__set_randomizer)				\
+	.set_randomizer = __set_randomizer
+
 #define SPINAND_INFO(__model, __id, __memorg, __eccreq, __op_variants,	\
 		     __flags, ...)					\
 	{								\
@@ -634,6 +639,7 @@ struct spinand_dirmap {
  * @user_otp: SPI NAND user OTP info.
  * @read_retries: the number of read retry modes supported
  * @set_read_retry: Enable/disable the read retry feature
+ * @set_randomizer: Enable the randomizer feature
  */
 struct spinand_device {
 	struct nand_device base;
@@ -667,6 +673,7 @@ struct spinand_device {
 	bool cont_read_possible;
 	int (*set_cont_read)(struct spinand_device *spinand,
 			     bool enable);
+	int (*set_randomizer)(struct spinand_device *spinand);
 
 	const struct spinand_fact_otp *fact_otp;
 	const struct spinand_user_otp *user_otp;
-- 
2.25.1

[PATCH v2 3/3] mtd: spi-nand: macronix: Add randomizer support

[Cheng Ming Lin]

From: Cheng Ming Lin <chengminglin@mxic.com.tw>

Enable randomizer function by specific flowchart to set the default value
of RANDEN to 1.

Randomizer introduces a new DT property "mxic,randopt" to define the
randomizer area per page.

The penalty of randomizer are subpage accesses prohibited and more time
period is needed in program operation and entering deep power-down mode.
i.e., tPROG 320us to 360us (randomizer enabled).

Signed-off-by: Cheng Ming Lin <chengminglin@mxic.com.tw>
---
 drivers/mtd/nand/spi/macronix.c | 89 +++++++++++++++++++++++++++++----
 1 file changed, 79 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/nand/spi/macronix.c b/drivers/mtd/nand/spi/macronix.c
index edf63b999..7450ee1d3 100644
--- a/drivers/mtd/nand/spi/macronix.c
+++ b/drivers/mtd/nand/spi/macronix.c
@@ -14,6 +14,10 @@
 #define MACRONIX_ECCSR_BF_LAST_PAGE(eccsr) FIELD_GET(GENMASK(3, 0), eccsr)
 #define MACRONIX_ECCSR_BF_ACCUMULATED_PAGES(eccsr) FIELD_GET(GENMASK(7, 4), eccsr)
 #define MACRONIX_CFG_CONT_READ         BIT(2)
+#define MACRONIX_CFG_ENPGM BIT(0)
+#define MACRONIX_CFG_RANDEN BIT(1)
+#define MACRONIX_CFG_RANDOPT BIT(2)
+#define MACRONIX_FEATURE_ADDR_RANDOMIZER 0x10
 #define MACRONIX_FEATURE_ADDR_READ_RETRY 0x70
 #define MACRONIX_NUM_READ_RETRY_MODES 5
 
@@ -155,6 +159,61 @@ static int macronix_set_read_retry(struct spinand_device *spinand,
 	return spi_mem_exec_op(spinand->spimem, &op);
 }
 
+static int macronix_set_randomizer(struct spinand_device *spinand)
+{
+	struct spi_mem_op exec_op = SPINAND_PROG_EXEC_1S_1S_0_OP(0);
+	struct nand_device *nand = spinand_to_nand(spinand);
+	struct device_node *dn = nanddev_get_of_node(nand);
+	int randopt, ret;
+	u8 cfg, status;
+
+	ret = spinand_read_reg_op(spinand, MACRONIX_FEATURE_ADDR_RANDOMIZER, &cfg);
+	if (ret)
+		return ret;
+	if (cfg)
+		return 0;
+
+	cfg = MACRONIX_CFG_ENPGM | MACRONIX_CFG_RANDEN;
+	randopt = of_property_read_bool(dn, "mxic,randopt");
+	if (randopt)
+		cfg |= MACRONIX_CFG_RANDOPT;
+
+	ret = spinand_write_reg_op(spinand, MACRONIX_FEATURE_ADDR_RANDOMIZER, cfg);
+	if (ret)
+		return ret;
+
+	ret = spinand_write_enable_op(spinand);
+	if (ret)
+		return ret;
+
+	ret = spi_mem_exec_op(spinand->spimem, &exec_op);
+	if (ret)
+		return ret;
+
+	ret = spinand_wait(spinand,
+			   SPINAND_WRITE_INITIAL_DELAY_US,
+			   SPINAND_WRITE_POLL_DELAY_US,
+			   &status);
+	if (ret)
+		return ret;
+
+	if (status & STATUS_PROG_FAILED)
+		return -EIO;
+
+	ret = spinand_read_reg_op(spinand, MACRONIX_FEATURE_ADDR_RANDOMIZER, &status);
+	if (ret)
+		return ret;
+	if (status != cfg)
+		return -EIO;
+
+	cfg &= ~MACRONIX_CFG_ENPGM;
+	ret = spinand_write_reg_op(spinand, MACRONIX_FEATURE_ADDR_RANDOMIZER, cfg);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
 static const struct spinand_info macronix_spinand_table[] = {
 	SPINAND_INFO("MX35LF1GE4AB",
 		     SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x12),
@@ -213,7 +272,8 @@ static const struct spinand_info macronix_spinand_table[] = {
 		     SPINAND_HAS_QE_BIT,
 		     SPINAND_ECCINFO(&mx35lfxge4ab_ooblayout, NULL),
 		     SPINAND_READ_RETRY(MACRONIX_NUM_READ_RETRY_MODES,
-					macronix_set_read_retry)),
+					macronix_set_read_retry),
+		     SPINAND_RANDOMIZER(macronix_set_randomizer)),
 	SPINAND_INFO("MX35LF2G24AD",
 		     SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x24, 0x03),
 		     NAND_MEMORG(1, 2048, 128, 64, 2048, 40, 2, 1, 1),
@@ -225,7 +285,8 @@ static const struct spinand_info macronix_spinand_table[] = {
 		     SPINAND_HAS_PROG_PLANE_SELECT_BIT,
 		     SPINAND_ECCINFO(&mx35lfxge4ab_ooblayout, NULL),
 		     SPINAND_READ_RETRY(MACRONIX_NUM_READ_RETRY_MODES,
-					macronix_set_read_retry)),
+					macronix_set_read_retry),
+		     SPINAND_RANDOMIZER(macronix_set_randomizer)),
 	SPINAND_INFO("MX35LF2G24AD-Z4I8",
 		     SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x64, 0x03),
 		     NAND_MEMORG(1, 2048, 128, 64, 2048, 40, 1, 1, 1),
@@ -236,7 +297,8 @@ static const struct spinand_info macronix_spinand_table[] = {
 		     SPINAND_HAS_QE_BIT,
 		     SPINAND_ECCINFO(&mx35lfxge4ab_ooblayout, NULL),
 		     SPINAND_READ_RETRY(MACRONIX_NUM_READ_RETRY_MODES,
-					macronix_set_read_retry)),
+					macronix_set_read_retry),
+		     SPINAND_RANDOMIZER(macronix_set_randomizer)),
 	SPINAND_INFO("MX35LF4G24AD",
 		     SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x35, 0x03),
 		     NAND_MEMORG(1, 4096, 256, 64, 2048, 40, 2, 1, 1),
@@ -248,7 +310,8 @@ static const struct spinand_info macronix_spinand_table[] = {
 		     SPINAND_HAS_PROG_PLANE_SELECT_BIT,
 		     SPINAND_ECCINFO(&mx35lfxge4ab_ooblayout, NULL),
 		     SPINAND_READ_RETRY(MACRONIX_NUM_READ_RETRY_MODES,
-					macronix_set_read_retry)),
+					macronix_set_read_retry),
+		     SPINAND_RANDOMIZER(macronix_set_randomizer)),
 	SPINAND_INFO("MX35LF4G24AD-Z4I8",
 		     SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x75, 0x03),
 		     NAND_MEMORG(1, 4096, 256, 64, 2048, 40, 1, 1, 1),
@@ -259,7 +322,8 @@ static const struct spinand_info macronix_spinand_table[] = {
 		     SPINAND_HAS_QE_BIT,
 		     SPINAND_ECCINFO(&mx35lfxge4ab_ooblayout, NULL),
 		     SPINAND_READ_RETRY(MACRONIX_NUM_READ_RETRY_MODES,
-					macronix_set_read_retry)),
+					macronix_set_read_retry),
+		     SPINAND_RANDOMIZER(macronix_set_randomizer)),
 	SPINAND_INFO("MX31LF1GE4BC",
 		     SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x1e),
 		     NAND_MEMORG(1, 2048, 64, 64, 1024, 20, 1, 1, 1),
@@ -305,7 +369,8 @@ static const struct spinand_info macronix_spinand_table[] = {
 		     SPINAND_ECCINFO(&mx35lfxge4ab_ooblayout,
 				     macronix_ecc_get_status),
 		     SPINAND_READ_RETRY(MACRONIX_NUM_READ_RETRY_MODES,
-					macronix_set_read_retry)),
+					macronix_set_read_retry),
+		     SPINAND_RANDOMIZER(macronix_set_randomizer)),
 	SPINAND_INFO("MX35UF4G24AD-Z4I8",
 		     SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0xf5, 0x03),
 		     NAND_MEMORG(1, 4096, 256, 64, 2048, 40, 1, 1, 1),
@@ -317,7 +382,8 @@ static const struct spinand_info macronix_spinand_table[] = {
 		     SPINAND_ECCINFO(&mx35lfxge4ab_ooblayout,
 				     macronix_ecc_get_status),
 		     SPINAND_READ_RETRY(MACRONIX_NUM_READ_RETRY_MODES,
-					macronix_set_read_retry)),
+					macronix_set_read_retry),
+		     SPINAND_RANDOMIZER(macronix_set_randomizer)),
 	SPINAND_INFO("MX35UF4GE4AD",
 		     SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0xb7, 0x03),
 		     NAND_MEMORG(1, 4096, 256, 64, 2048, 40, 1, 1, 1),
@@ -355,7 +421,8 @@ static const struct spinand_info macronix_spinand_table[] = {
 		     SPINAND_ECCINFO(&mx35lfxge4ab_ooblayout,
 				     macronix_ecc_get_status),
 		     SPINAND_READ_RETRY(MACRONIX_NUM_READ_RETRY_MODES,
-					macronix_set_read_retry)),
+					macronix_set_read_retry),
+		     SPINAND_RANDOMIZER(macronix_set_randomizer)),
 	SPINAND_INFO("MX35UF2G24AD-Z4I8",
 		     SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0xe4, 0x03),
 		     NAND_MEMORG(1, 2048, 128, 64, 2048, 40, 1, 1, 1),
@@ -367,7 +434,8 @@ static const struct spinand_info macronix_spinand_table[] = {
 		     SPINAND_ECCINFO(&mx35lfxge4ab_ooblayout,
 				     macronix_ecc_get_status),
 		     SPINAND_READ_RETRY(MACRONIX_NUM_READ_RETRY_MODES,
-					macronix_set_read_retry)),
+					macronix_set_read_retry),
+		     SPINAND_RANDOMIZER(macronix_set_randomizer)),
 	SPINAND_INFO("MX35UF2GE4AD",
 		     SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0xa6, 0x03),
 		     NAND_MEMORG(1, 2048, 128, 64, 2048, 40, 1, 1, 1),
@@ -413,7 +481,8 @@ static const struct spinand_info macronix_spinand_table[] = {
 		     SPINAND_ECCINFO(&mx35lfxge4ab_ooblayout,
 				     macronix_ecc_get_status),
 		     SPINAND_READ_RETRY(MACRONIX_NUM_READ_RETRY_MODES,
-					macronix_set_read_retry)),
+					macronix_set_read_retry),
+		     SPINAND_RANDOMIZER(macronix_set_randomizer)),
 	SPINAND_INFO("MX35UF1GE4AD",
 		     SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x96, 0x03),
 		     NAND_MEMORG(1, 2048, 128, 64, 1024, 20, 1, 1, 1),
-- 
2.25.1

Re: [PATCH v2 3/3] mtd: spi-nand: macronix: Add randomizer support

[Miquel Raynal]

> +static int macronix_set_randomizer(struct spinand_device *spinand)
> +{
> +	struct spi_mem_op exec_op = SPINAND_PROG_EXEC_1S_1S_0_OP(0);
> +	struct nand_device *nand = spinand_to_nand(spinand);
> +	struct device_node *dn = nanddev_get_of_node(nand);
> +	int randopt, ret;
> +	u8 cfg, status;
> +
> +	ret = spinand_read_reg_op(spinand, MACRONIX_FEATURE_ADDR_RANDOMIZER, &cfg);
> +	if (ret)
> +		return ret;
> +	if (cfg)
> +		return 0;
> +
> +	cfg = MACRONIX_CFG_ENPGM | MACRONIX_CFG_RANDEN;
> +	randopt = of_property_read_bool(dn, "mxic,randopt");

Isn't that a leftover?

Thanks,
Miquèl

Re: [PATCH v2 3/3] mtd: spi-nand: macronix: Add randomizer support

[Cheng Ming Lin]

Hi Miquel,

Miquel Raynal <miquel.raynal@bootlin.com> 於 2025年9月10日 週三 下午5:12寫道：
>
>
> > +static int macronix_set_randomizer(struct spinand_device *spinand)
> > +{
> > +     struct spi_mem_op exec_op = SPINAND_PROG_EXEC_1S_1S_0_OP(0);
> > +     struct nand_device *nand = spinand_to_nand(spinand);
> > +     struct device_node *dn = nanddev_get_of_node(nand);
> > +     int randopt, ret;
> > +     u8 cfg, status;
> > +
> > +     ret = spinand_read_reg_op(spinand, MACRONIX_FEATURE_ADDR_RANDOMIZER, &cfg);
> > +     if (ret)
> > +             return ret;
> > +     if (cfg)
> > +             return 0;
> > +
> > +     cfg = MACRONIX_CFG_ENPGM | MACRONIX_CFG_RANDEN;
> > +     randopt = of_property_read_bool(dn, "mxic,randopt");
>
> Isn't that a leftover?

The property "mxic,randopt" corresponds to bit2 of the configuration
register 0x10. Its purpose is to control whether the randomizer also
covers the initial portion of the spare area.

Since the randomizer feature is only documented in Macronix datasheets,
it is not clear whether the "randopt" bit is used by all vendors. For
this reason, the handling is placed inside macronix.c.

For reference, please see page 28 of the following document:
Link: https://www.mxic.com.tw/Lists/Datasheet/Attachments/9036/MX35LF4G24AD,%203V,%204Gb,%20v1.4.pdf

>
> Thanks,
> Miquèl

Thanks,
Cheng Ming Lin

Re: [PATCH v2 3/3] mtd: spi-nand: macronix: Add randomizer support

[Miquel Raynal]

On 10/09/2025 at 17:26:13 +08, Cheng Ming Lin <linchengming884@gmail.com> wrote:

> Hi Miquel,
>
> Miquel Raynal <miquel.raynal@bootlin.com> 於 2025年9月10日 週三 下午5:12寫道：
>>
>>
>> > +static int macronix_set_randomizer(struct spinand_device *spinand)
>> > +{
>> > +     struct spi_mem_op exec_op = SPINAND_PROG_EXEC_1S_1S_0_OP(0);
>> > +     struct nand_device *nand = spinand_to_nand(spinand);
>> > +     struct device_node *dn = nanddev_get_of_node(nand);
>> > +     int randopt, ret;
>> > +     u8 cfg, status;
>> > +
>> > +     ret = spinand_read_reg_op(spinand, MACRONIX_FEATURE_ADDR_RANDOMIZER, &cfg);
>> > +     if (ret)
>> > +             return ret;
>> > +     if (cfg)
>> > +             return 0;
>> > +
>> > +     cfg = MACRONIX_CFG_ENPGM | MACRONIX_CFG_RANDEN;
>> > +     randopt = of_property_read_bool(dn, "mxic,randopt");
>>
>> Isn't that a leftover?
>
> The property "mxic,randopt" corresponds to bit2 of the configuration
> register 0x10. Its purpose is to control whether the randomizer also
> covers the initial portion of the spare area.

Do we need a DT property for that?

In any case, it must be declared in the bindings (which I do not think
it is?).

> Since the randomizer feature is only documented in Macronix datasheets,
> it is not clear whether the "randopt" bit is used by all vendors. For
> this reason, the handling is placed inside macronix.c.

Didn't we discuss in the past of a volatile version for SPI NAND
devices? I thought we could use a volatile approach instead.

Thanks,
Miquèl

Re: [PATCH v2 3/3] mtd: spi-nand: macronix: Add randomizer support

[Cheng Ming Lin]

Hi Miquel,

Miquel Raynal <miquel.raynal@bootlin.com> 於 2025年9月10日 週三 下午5:43寫道：
>
> On 10/09/2025 at 17:26:13 +08, Cheng Ming Lin <linchengming884@gmail.com> wrote:
>
> > Hi Miquel,
> >
> > Miquel Raynal <miquel.raynal@bootlin.com> 於 2025年9月10日 週三 下午5:12寫道：
> >>
> >>
> >> > +static int macronix_set_randomizer(struct spinand_device *spinand)
> >> > +{
> >> > +     struct spi_mem_op exec_op = SPINAND_PROG_EXEC_1S_1S_0_OP(0);
> >> > +     struct nand_device *nand = spinand_to_nand(spinand);
> >> > +     struct device_node *dn = nanddev_get_of_node(nand);
> >> > +     int randopt, ret;
> >> > +     u8 cfg, status;
> >> > +
> >> > +     ret = spinand_read_reg_op(spinand, MACRONIX_FEATURE_ADDR_RANDOMIZER, &cfg);
> >> > +     if (ret)
> >> > +             return ret;
> >> > +     if (cfg)
> >> > +             return 0;
> >> > +
> >> > +     cfg = MACRONIX_CFG_ENPGM | MACRONIX_CFG_RANDEN;
> >> > +     randopt = of_property_read_bool(dn, "mxic,randopt");
> >>
> >> Isn't that a leftover?
> >
> > The property "mxic,randopt" corresponds to bit2 of the configuration
> > register 0x10. Its purpose is to control whether the randomizer also
> > covers the initial portion of the spare area.
>
> Do we need a DT property for that?
>
> In any case, it must be declared in the bindings (which I do not think
> it is?).
>
> > Since the randomizer feature is only documented in Macronix datasheets,
> > it is not clear whether the "randopt" bit is used by all vendors. For
> > this reason, the handling is placed inside macronix.c.
>
> Didn't we discuss in the past of a volatile version for SPI NAND
> devices? I thought we could use a volatile approach instead.

I think a DT property makes sense here. Once the randomizer feature is
enabled, the range it covers must be defined as well. If we rely on a
volatile approach, the randomizer coverage might change dynamically,
which I believe is less safe and harder to guarantee consistency.

>
> Thanks,
> Miquèl

Thanks,
Cheng Ming Lin