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

[Miquel Raynal <miquel.raynal@bootlin.com>]

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