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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230731110428.7d581494@xps-13>
Date:   Mon, 31 Jul 2023 11:04:28 +0200
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Johan Jonker <jbx6244@...il.com>
Cc:     Conor Dooley <conor@...nel.org>, richard@....at, vigneshr@...com,
        robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        conor+dt@...nel.org, linux-mtd@...ts.infradead.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v1 1/2] dt-bindings: mtd: nand-controller: add
 nand-skip-bbtscan and nand-no-bbm-quirk DT options

Hi Johan, Richard,

jbx6244@...il.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@...il.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