Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 31 Jul 2023 11:04:28 +0200
From:   Miquel Raynal <miquel.raynal@bootlin.com>
To:     Johan Jonker <jbx6244@gmail.com>
Cc:     Conor Dooley <conor@kernel.org>, richard@nod.at, vigneshr@ti.com,
        robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
        conor+dt@kernel.org, linux-mtd@lists.infradead.org,
        linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v1 1/2] dt-bindings: mtd: nand-controller: add
 nand-skip-bbtscan and nand-no-bbm-quirk DT options
Message-ID: <20230731110428.7d581494@xps-13>
In-Reply-To: <c919ba00-f741-33ff-cc6f-18988c52f14d@gmail.com>
References: <61c84262-cd98-1e60-d95b-9b0492083994@gmail.com>
        <20230718-curfew-jumble-aeafe95c5cc7@spud>
        <c919ba00-f741-33ff-cc6f-18988c52f14d@gmail.com>
Organization: Bootlin
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

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: =20
> >> 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 opt=
ion
> >> https://lore.kernel.org/linux-mtd/1618382560.2326931.1689261435022.Jav=
aMail.zimbra@nod.at/
> >> ---
> >>  .../devicetree/bindings/mtd/nand-controller.yaml    | 13 +++++++++++++
> >>  1 file changed, 13 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yam=
l 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 BB=
M 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 sho=
uldn'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 =20
> >=20
> > While this seems okay, as it seems to describe facet of the hardware...
> >  =20
> >> +      nand-skip-bbtscan:
> >> +        description:
> >> +          This option skips the BBT scan during initialization.
> >> +        $ref: /schemas/types.yaml#/definitions/flag =20
> >=20
> > ...this seems to be used to control the behaviour of software, and does
> > not describe the underlying hardware.
> >=20
> > Maybe I'm off, but the description of the property does not hint at the
> > aspect of the hardware that this addresses. =20
>=20
> Hi Conor,
>=20
>=20
> Thank you!
> Your point is correct.
> However I need both flags to change MTD software driver probe behavior in=
 case of formatting.
>=20
> Patch was made after comment by  Miquel:
> 'I would rather prefer a DT property which says "do not use the
> standard pattern".'
>=20
> 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 agai=
n? 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=C3=A8l