[PATCH v1 1/2] dt-bindings: mtd: nand-controller: add nand-skip-bbtscan and nand-no-bbm-quirk DT options

[PATCH v1 1/2] dt-bindings: mtd: nand-controller: add nand-skip-bbtscan and nand-no-bbm-quirk DT options

[Johan Jonker]

A NAND chip can contain a different data format then the MTD framework
expects in the erase blocks for the Bad Block Table(BBT).
Result is a failed probe, while nothing wrong with the hardware.
Some MTD flags need to be set to gain access again.

Skip the automatic BBT scan with the NAND_SKIP_BBTSCAN option
so that the original content is unchanged during the driver probe.
The NAND_NO_BBM_QUIRK option allows us to erase bad blocks with
the nand_erase_nand() function and the flash_erase command.

Add nand-skip-bbtscan and nand-no-bbm-quirk Device Tree options,
so the user has the "freedom of choice" by neutral
access mode to read and write in whatever format is needed.

Signed-off-by: Johan Jonker <jbx6244@gmail.com>
---

Previous discussion:
[PATCH v3 3/3] mtd: rawnand: rockchip-nand-controller: add skipbbt option
https://lore.kernel.org/linux-mtd/1618382560.2326931.1689261435022.JavaMail.zimbra@nod.at/
---
 .../devicetree/bindings/mtd/nand-controller.yaml    | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
index f70a32d2d9d4..ca04d06a0377 100644
--- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
+++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
@@ -103,6 +103,19 @@ patternProperties:
           the boot ROM or similar restrictions.
         $ref: /schemas/types.yaml#/definitions/flag

+      nand-no-bbm-quirk:
+        description:
+          Some controllers with pipelined ECC engines override the BBM marker with
+          data or ECC bytes, thus making bad block detection through bad block marker
+          impossible. Let's flag those chips so the core knows it shouldn't check the
+          BBM and consider all blocks good.
+        $ref: /schemas/types.yaml#/definitions/flag
+
+      nand-skip-bbtscan:
+        description:
+          This option skips the BBT scan during initialization.
+        $ref: /schemas/types.yaml#/definitions/flag
+
       nand-rb:
         description:
           Contains the native Ready/Busy IDs.
--
2.30.2

[PATCH v1 2/2] mtd: rawnand: add nand-skip-bbtscan and nand-no-bbm-quirk DT options

[Johan Jonker]

A NAND chip can contain a different data format then the MTD framework
expects in the erase blocks for the Bad Block Table(BBT).
Result is a failed probe, while nothing wrong with the hardware.
Some MTD flags need to be set to gain access again.

Skip the automatic BBT scan with the NAND_SKIP_BBTSCAN option
so that the original content is unchanged during the driver probe.
The NAND_NO_BBM_QUIRK option allows us to erase bad blocks with
the nand_erase_nand() function and the flash_erase command.

Add nand-skip-bbtscan and nand-no-bbm-quirk Device Tree options,
so the user has the "freedom of choice" by neutral
access mode to read and write in whatever format is needed.

Signed-off-by: Johan Jonker <jbx6244@gmail.com>
---

Previous discussion:
[PATCH v3 3/3] mtd: rawnand: rockchip-nand-controller: add skipbbt option
https://lore.kernel.org/linux-mtd/1618382560.2326931.1689261435022.JavaMail.zimbra@nod.at/
---
 drivers/mtd/nand/raw/nand_base.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index a6af521832aa..f0fa5c3519b1 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5521,6 +5521,12 @@ static int rawnand_dt_init(struct nand_chip *chip)
 	if (of_property_read_bool(dn, "nand-is-boot-medium"))
 		chip->options |= NAND_IS_BOOT_MEDIUM;

+	if (of_property_read_bool(dn, "nand-no-bbm-quirk"))
+		chip->options |= NAND_NO_BBM_QUIRK;
+
+	if (of_property_read_bool(dn, "nand-skip-bbtscan"))
+		chip->options |= NAND_SKIP_BBTSCAN;
+
 	if (of_property_read_bool(dn, "nand-on-flash-bbt"))
 		chip->bbt_options |= NAND_BBT_USE_FLASH;

--
2.30.2

Re: [PATCH v1 2/2] mtd: rawnand: add nand-skip-bbtscan and nand-no-bbm-quirk DT options

[Miquel Raynal]

Hi Johan,

jbx6244@gmail.com wrote on Sat, 15 Jul 2023 12:49:18 +0200:

> A NAND chip can contain a different data format then the MTD framework
> expects in the erase blocks for the Bad Block Table(BBT).
> Result is a failed probe, while nothing wrong with the hardware.
> Some MTD flags need to be set to gain access again.
> 
> Skip the automatic BBT scan with the NAND_SKIP_BBTSCAN option
> so that the original content is unchanged during the driver probe.
> The NAND_NO_BBM_QUIRK option allows us to erase bad blocks with
> the nand_erase_nand() function and the flash_erase command.
> 
> Add nand-skip-bbtscan and nand-no-bbm-quirk Device Tree options,
> so the user has the "freedom of choice" by neutral
> access mode to read and write in whatever format is needed.

This sounds like a partial solution. How do you handle bad blocks?

> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
> ---
> 
> Previous discussion:
> [PATCH v3 3/3] mtd: rawnand: rockchip-nand-controller: add skipbbt option
> https://lore.kernel.org/linux-mtd/1618382560.2326931.1689261435022.JavaMail.zimbra@nod.at/
> ---
>  drivers/mtd/nand/raw/nand_base.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
> index a6af521832aa..f0fa5c3519b1 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -5521,6 +5521,12 @@ static int rawnand_dt_init(struct nand_chip *chip)
>  	if (of_property_read_bool(dn, "nand-is-boot-medium"))
>  		chip->options |= NAND_IS_BOOT_MEDIUM;
> 
> +	if (of_property_read_bool(dn, "nand-no-bbm-quirk"))
> +		chip->options |= NAND_NO_BBM_QUIRK;
> +
> +	if (of_property_read_bool(dn, "nand-skip-bbtscan"))
> +		chip->options |= NAND_SKIP_BBTSCAN;
> +
>  	if (of_property_read_bool(dn, "nand-on-flash-bbt"))
>  		chip->bbt_options |= NAND_BBT_USE_FLASH;
> 
> --
> 2.30.2
> 


Thanks,
Miquèl

Re: [PATCH v1 2/2] mtd: rawnand: add nand-skip-bbtscan and nand-no-bbm-quirk DT options

[Johan Jonker]

On 7/15/23 17:55, Miquel Raynal wrote:
> Hi Johan,
> 
> jbx6244@gmail.com wrote on Sat, 15 Jul 2023 12:49:18 +0200:
> 
>> A NAND chip can contain a different data format then the MTD framework
>> expects in the erase blocks for the Bad Block Table(BBT).
>> Result is a failed probe, while nothing wrong with the hardware.
>> Some MTD flags need to be set to gain access again.
>>
>> Skip the automatic BBT scan with the NAND_SKIP_BBTSCAN option
>> so that the original content is unchanged during the driver probe.
>> The NAND_NO_BBM_QUIRK option allows us to erase bad blocks with
>> the nand_erase_nand() function and the flash_erase command.
>>
>> Add nand-skip-bbtscan and nand-no-bbm-quirk Device Tree options,
>> so the user has the "freedom of choice" by neutral
>> access mode to read and write in whatever format is needed.
> 

> This sounds like a partial solution. How do you handle bad blocks?

Hi Miquel,

See below some Rockchip related links:

The file rk_ftl_arm_v7.S is marked GPL2, so I can freely refer/decode/hack to/in that.
For rk3066 a closed source piece called usbplug is still needed to program initial U-boot.
This usbplug contains similar code as in the S file and formats the NAND for FTL. 
U-boot is not small enough yet (WIP if I have the time) to replace that.
Long story short is that on Rockchip NAND's we can expect pages with various ECC and scrambled/randomized all over the place.

One effect is that when the MTD framework driver is probed a first time the BBT pages don't look what was expected.
For this first probe to be successful I must be able to turn of the MTD internal BBT scan and then erase/format all blocks except boot blocks of course.
During this first run bad blocks are handled by/tested/kept track of/set BBM in user space.
This is not meant as permanent mode.(except maybe if this S file is converted as open source FTL (WIP))

Richard doesn't like module parameters, so I can't simply do modprobe for example in a script.
After that the whole kernel/MTD must rebooted without these DT options.
 
This patch does make parameters/flags available for all.
If that is too much freedom to handle I can parse them in the Rockchip driver, let me know.
 
Linux always gets away with the "it must be generic functionality" excuse.
In U-boot there is the same driver with little or no interaction with the user, so we must deal with that.
Please advise how we can solve this in a simple nice automated way.


Johan

===

function FlashSetRandomizer()
https://github.com/rockchip-linux/kernel/blob/develop-4.4/drivers/rk_nand/rk_ftl_arm_v7.S#L120
https://github.com/rockchip-linux/u-boot/blob/next-dev/drivers/rknand/rk_ftl_arm_v7.S#L199

Proof of concept for U-boot:
[v2,06/11] rockchip: idb: add randomizer option
http://patchwork.ozlabs.org/project/uboot/patch/0b295d0e-53d6-b35a-3058-861e203b4d83@gmail.com/

> 
>> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
>> ---
>>
>> Previous discussion:
>> [PATCH v3 3/3] mtd: rawnand: rockchip-nand-controller: add skipbbt option
>> https://lore.kernel.org/linux-mtd/1618382560.2326931.1689261435022.JavaMail.zimbra@nod.at/
>> ---
>>  drivers/mtd/nand/raw/nand_base.c | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
>> index a6af521832aa..f0fa5c3519b1 100644
>> --- a/drivers/mtd/nand/raw/nand_base.c
>> +++ b/drivers/mtd/nand/raw/nand_base.c
>> @@ -5521,6 +5521,12 @@ static int rawnand_dt_init(struct nand_chip *chip)
>>  	if (of_property_read_bool(dn, "nand-is-boot-medium"))
>>  		chip->options |= NAND_IS_BOOT_MEDIUM;
>>
>> +	if (of_property_read_bool(dn, "nand-no-bbm-quirk"))
>> +		chip->options |= NAND_NO_BBM_QUIRK;
>> +
>> +	if (of_property_read_bool(dn, "nand-skip-bbtscan"))
>> +		chip->options |= NAND_SKIP_BBTSCAN;
>> +
>>  	if (of_property_read_bool(dn, "nand-on-flash-bbt"))
>>  		chip->bbt_options |= NAND_BBT_USE_FLASH;
>>
>> --
>> 2.30.2
>>
> 
> 
> Thanks,
> Miquèl

Re: [PATCH v1 2/2] mtd: rawnand: add nand-skip-bbtscan and nand-no-bbm-quirk DT options

[Miquel Raynal]

Hi Richard,

jbx6244@gmail.com wrote on Mon, 17 Jul 2023 12:49:43 +0200:

> On 7/15/23 17:55, Miquel Raynal wrote:
> > Hi Johan,
> > 
> > jbx6244@gmail.com wrote on Sat, 15 Jul 2023 12:49:18 +0200:
> >   
> >> A NAND chip can contain a different data format then the MTD framework
> >> expects in the erase blocks for the Bad Block Table(BBT).
> >> Result is a failed probe, while nothing wrong with the hardware.
> >> Some MTD flags need to be set to gain access again.
> >>
> >> Skip the automatic BBT scan with the NAND_SKIP_BBTSCAN option
> >> so that the original content is unchanged during the driver probe.
> >> The NAND_NO_BBM_QUIRK option allows us to erase bad blocks with
> >> the nand_erase_nand() function and the flash_erase command.
> >>
> >> Add nand-skip-bbtscan and nand-no-bbm-quirk Device Tree options,
> >> so the user has the "freedom of choice" by neutral
> >> access mode to read and write in whatever format is needed.  
> >   
> 
> > This sounds like a partial solution. How do you handle bad blocks?  
> 
> Hi Miquel,
> 
> See below some Rockchip related links:
> 
> The file rk_ftl_arm_v7.S is marked GPL2, so I can freely refer/decode/hack to/in that.
> For rk3066 a closed source piece called usbplug is still needed to program initial U-boot.
> This usbplug contains similar code as in the S file and formats the NAND for FTL. 
> U-boot is not small enough yet (WIP if I have the time) to replace that.
> Long story short is that on Rockchip NAND's we can expect pages with various ECC and scrambled/randomized all over the place.
> 
> One effect is that when the MTD framework driver is probed a first time the BBT pages don't look what was expected.
> For this first probe to be successful I must be able to turn of the MTD internal BBT scan and then erase/format all blocks except boot blocks of course.
> During this first run bad blocks are handled by/tested/kept track of/set BBM in user space.
> This is not meant as permanent mode.(except maybe if this S file is converted as open source FTL (WIP))
> 
> Richard doesn't like module parameters, so I can't simply do modprobe for example in a script.
> After that the whole kernel/MTD must rebooted without these DT options.

Richard, do you think we should support such use case? Any direction
would help.

>  
> This patch does make parameters/flags available for all.
> If that is too much freedom to handle I can parse them in the Rockchip driver, let me know.
>  
> Linux always gets away with the "it must be generic functionality" excuse.
> In U-boot there is the same driver with little or no interaction with the user, so we must deal with that.
> Please advise how we can solve this in a simple nice automated way.
> 
> 
> Johan
> 
> ===
> 
> function FlashSetRandomizer()
> https://github.com/rockchip-linux/kernel/blob/develop-4.4/drivers/rk_nand/rk_ftl_arm_v7.S#L120
> https://github.com/rockchip-linux/u-boot/blob/next-dev/drivers/rknand/rk_ftl_arm_v7.S#L199
> 
> Proof of concept for U-boot:
> [v2,06/11] rockchip: idb: add randomizer option
> http://patchwork.ozlabs.org/project/uboot/patch/0b295d0e-53d6-b35a-3058-861e203b4d83@gmail.com/
> 
> >   
> >> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
> >> ---
> >>
> >> Previous discussion:
> >> [PATCH v3 3/3] mtd: rawnand: rockchip-nand-controller: add skipbbt option
> >> https://lore.kernel.org/linux-mtd/1618382560.2326931.1689261435022.JavaMail.zimbra@nod.at/
> >> ---
> >>  drivers/mtd/nand/raw/nand_base.c | 6 ++++++
> >>  1 file changed, 6 insertions(+)
> >>
> >> diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
> >> index a6af521832aa..f0fa5c3519b1 100644
> >> --- a/drivers/mtd/nand/raw/nand_base.c
> >> +++ b/drivers/mtd/nand/raw/nand_base.c
> >> @@ -5521,6 +5521,12 @@ static int rawnand_dt_init(struct nand_chip *chip)
> >>  	if (of_property_read_bool(dn, "nand-is-boot-medium"))
> >>  		chip->options |= NAND_IS_BOOT_MEDIUM;
> >>
> >> +	if (of_property_read_bool(dn, "nand-no-bbm-quirk"))
> >> +		chip->options |= NAND_NO_BBM_QUIRK;
> >> +
> >> +	if (of_property_read_bool(dn, "nand-skip-bbtscan"))
> >> +		chip->options |= NAND_SKIP_BBTSCAN;
> >> +
> >>  	if (of_property_read_bool(dn, "nand-on-flash-bbt"))
> >>  		chip->bbt_options |= NAND_BBT_USE_FLASH;
> >>
> >> --
> >> 2.30.2
> >>  
> > 
> > 
> > Thanks,
> > Miquèl  


Thanks,
Miquèl

Re: [PATCH v1 1/2] dt-bindings: mtd: nand-controller: add nand-skip-bbtscan and nand-no-bbm-quirk DT options

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 2687 bytes --]

On Sat, Jul 15, 2023 at 12:48:16PM +0200, Johan Jonker wrote:
> A NAND chip can contain a different data format then the MTD framework
> expects in the erase blocks for the Bad Block Table(BBT).
> Result is a failed probe, while nothing wrong with the hardware.
> Some MTD flags need to be set to gain access again.
> 
> Skip the automatic BBT scan with the NAND_SKIP_BBTSCAN option
> so that the original content is unchanged during the driver probe.
> The NAND_NO_BBM_QUIRK option allows us to erase bad blocks with
> the nand_erase_nand() function and the flash_erase command.
> 
> Add nand-skip-bbtscan and nand-no-bbm-quirk Device Tree options,
> so the user has the "freedom of choice" by neutral
> access mode to read and write in whatever format is needed.
> 
> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
> ---
> 
> Previous discussion:
> [PATCH v3 3/3] mtd: rawnand: rockchip-nand-controller: add skipbbt option
> https://lore.kernel.org/linux-mtd/1618382560.2326931.1689261435022.JavaMail.zimbra@nod.at/
> ---
>  .../devicetree/bindings/mtd/nand-controller.yaml    | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> index f70a32d2d9d4..ca04d06a0377 100644
> --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> @@ -103,6 +103,19 @@ patternProperties:
>            the boot ROM or similar restrictions.
>          $ref: /schemas/types.yaml#/definitions/flag
> 
> +      nand-no-bbm-quirk:
> +        description:
> +          Some controllers with pipelined ECC engines override the BBM marker with
> +          data or ECC bytes, thus making bad block detection through bad block marker
> +          impossible. Let's flag those chips so the core knows it shouldn't check the
> +          BBM and consider all blocks good.
> +        $ref: /schemas/types.yaml#/definitions/flag

While this seems okay, as it seems to describe facet of the hardware...

> +      nand-skip-bbtscan:
> +        description:
> +          This option skips the BBT scan during initialization.
> +        $ref: /schemas/types.yaml#/definitions/flag

...this seems to be used to control the behaviour of software, and does
not describe the underlying hardware.

Maybe I'm off, but the description of the property does not hint at the
aspect of the hardware that this addresses.

Thanks,
Conor.

> +
>        nand-rb:
>          description:
>            Contains the native Ready/Busy IDs.
> --
> 2.30.2
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v1 1/2] dt-bindings: mtd: nand-controller: add nand-skip-bbtscan and nand-no-bbm-quirk DT options

[Johan Jonker]

On 7/18/23 17:46, Conor Dooley wrote:
> On Sat, Jul 15, 2023 at 12:48:16PM +0200, Johan Jonker wrote:
>> A NAND chip can contain a different data format then the MTD framework
>> expects in the erase blocks for the Bad Block Table(BBT).
>> Result is a failed probe, while nothing wrong with the hardware.
>> Some MTD flags need to be set to gain access again.
>>
>> Skip the automatic BBT scan with the NAND_SKIP_BBTSCAN option
>> so that the original content is unchanged during the driver probe.
>> The NAND_NO_BBM_QUIRK option allows us to erase bad blocks with
>> the nand_erase_nand() function and the flash_erase command.
>>
>> Add nand-skip-bbtscan and nand-no-bbm-quirk Device Tree options,
>> so the user has the "freedom of choice" by neutral
>> access mode to read and write in whatever format is needed.
>>
>> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
>> ---
>>
>> Previous discussion:
>> [PATCH v3 3/3] mtd: rawnand: rockchip-nand-controller: add skipbbt option
>> https://lore.kernel.org/linux-mtd/1618382560.2326931.1689261435022.JavaMail.zimbra@nod.at/
>> ---
>>  .../devicetree/bindings/mtd/nand-controller.yaml    | 13 +++++++++++++
>>  1 file changed, 13 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
>> index f70a32d2d9d4..ca04d06a0377 100644
>> --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
>> +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
>> @@ -103,6 +103,19 @@ patternProperties:
>>            the boot ROM or similar restrictions.
>>          $ref: /schemas/types.yaml#/definitions/flag
>>
>> +      nand-no-bbm-quirk:
>> +        description:
>> +          Some controllers with pipelined ECC engines override the BBM marker with
>> +          data or ECC bytes, thus making bad block detection through bad block marker
>> +          impossible. Let's flag those chips so the core knows it shouldn't check the
>> +          BBM and consider all blocks good.
>> +        $ref: /schemas/types.yaml#/definitions/flag
> 
> While this seems okay, as it seems to describe facet of the hardware...
> 
>> +      nand-skip-bbtscan:
>> +        description:
>> +          This option skips the BBT scan during initialization.
>> +        $ref: /schemas/types.yaml#/definitions/flag
> 
> ...this seems to be used to control the behaviour of software, and does
> not describe the underlying hardware.
> 
> Maybe I'm off, but the description of the property does not hint at the
> aspect of the hardware that this addresses.

Hi Conor,


Thank you!
Your point is correct.
However I need both flags to change MTD software driver probe behavior in case of formatting.

Patch was made after comment by  Miquel:
'I would rather prefer a DT property which says "do not use the
standard pattern".'

DT should describe hardware and not software probe configuration.
Currently not aware what other options we have for module parameters.
Prefer my solution in the link. Could the MTD maintainer have a look again? Thanks!
Please advise.

Johan Jonker

> 
> Thanks,
> Conor.
> 
>> +
>>        nand-rb:
>>          description:
>>            Contains the native Ready/Busy IDs.
>> --
>> 2.30.2
>>

Re: [PATCH v1 1/2] dt-bindings: mtd: nand-controller: add nand-skip-bbtscan and nand-no-bbm-quirk DT options

[Miquel Raynal]

Hi Johan, Richard,

jbx6244@gmail.com wrote on Wed, 19 Jul 2023 21:39:24 +0200:

> On 7/18/23 17:46, Conor Dooley wrote:
> > On Sat, Jul 15, 2023 at 12:48:16PM +0200, Johan Jonker wrote:  
> >> A NAND chip can contain a different data format then the MTD framework
> >> expects in the erase blocks for the Bad Block Table(BBT).
> >> Result is a failed probe, while nothing wrong with the hardware.
> >> Some MTD flags need to be set to gain access again.
> >>
> >> Skip the automatic BBT scan with the NAND_SKIP_BBTSCAN option
> >> so that the original content is unchanged during the driver probe.
> >> The NAND_NO_BBM_QUIRK option allows us to erase bad blocks with
> >> the nand_erase_nand() function and the flash_erase command.
> >>
> >> Add nand-skip-bbtscan and nand-no-bbm-quirk Device Tree options,
> >> so the user has the "freedom of choice" by neutral
> >> access mode to read and write in whatever format is needed.
> >>
> >> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
> >> ---
> >>
> >> Previous discussion:
> >> [PATCH v3 3/3] mtd: rawnand: rockchip-nand-controller: add skipbbt option
> >> https://lore.kernel.org/linux-mtd/1618382560.2326931.1689261435022.JavaMail.zimbra@nod.at/
> >> ---
> >>  .../devicetree/bindings/mtd/nand-controller.yaml    | 13 +++++++++++++
> >>  1 file changed, 13 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> >> index f70a32d2d9d4..ca04d06a0377 100644
> >> --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> >> +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> >> @@ -103,6 +103,19 @@ patternProperties:
> >>            the boot ROM or similar restrictions.
> >>          $ref: /schemas/types.yaml#/definitions/flag
> >>
> >> +      nand-no-bbm-quirk:
> >> +        description:
> >> +          Some controllers with pipelined ECC engines override the BBM marker with
> >> +          data or ECC bytes, thus making bad block detection through bad block marker
> >> +          impossible. Let's flag those chips so the core knows it shouldn't check the
> >> +          BBM and consider all blocks good.

I am sorry but this is totally broken. We cannot just "consider all
blocks good".

> >> +        $ref: /schemas/types.yaml#/definitions/flag  
> > 
> > While this seems okay, as it seems to describe facet of the hardware...
> >   
> >> +      nand-skip-bbtscan:
> >> +        description:
> >> +          This option skips the BBT scan during initialization.
> >> +        $ref: /schemas/types.yaml#/definitions/flag  
> > 
> > ...this seems to be used to control the behaviour of software, and does
> > not describe the underlying hardware.
> > 
> > Maybe I'm off, but the description of the property does not hint at the
> > aspect of the hardware that this addresses.  
> 
> Hi Conor,
> 
> 
> Thank you!
> Your point is correct.
> However I need both flags to change MTD software driver probe behavior in case of formatting.
> 
> Patch was made after comment by  Miquel:
> 'I would rather prefer a DT property which says "do not use the
> standard pattern".'
> 
> DT should describe hardware and not software probe configuration.
> Currently not aware what other options we have for module parameters.
> Prefer my solution in the link. Could the MTD maintainer have a look again? Thanks!
> Please advise.

The more I think about this, the less I want to support it. You are
basically getting rid of any bad block support so in practice you don't
want to use mtd. Richard, what do you think? I have no strong opinion
about all this, but I just feel it's terribly wrong.

Thanks,
Miquèl