Hi Johan, Richard, jbx6244@xxxxxxxxx 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@xxxxxxxxx> > >> --- > >> > >> 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@xxxxxx/ > >> --- > >> .../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
