linux-kernel - Re: [PATCH 1/1] mtd: spinand: add support for Foresee FS35ND01G

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] [day] [month] [year] [list]

Date:   Tue, 5 Jan 2021 14:04:31 +0100
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Daniel Palmer <daniel@...f.com>
Cc:     linux-mtd@...ts.infradead.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        richard@....at, vigneshr@...com
Subject: Re: [PATCH 1/1] mtd: spinand: add support for Foresee FS35ND01G

Hi Daniel,

Daniel Palmer <daniel@...f.com> wrote on Tue, 5 Jan 2021 21:18:21 +0900:

> Hi Miquel,
> 
> On Mon, 4 Jan 2021 at 23:17, Miquel Raynal <miquel.raynal@...tlin.com> wrote:
> > Perhaps giving the link of the datasheet here makes sense.  
> 
> Noted. I'll put that into v2.
> 
> > > +#define SPINAND_MFR_LONGSYS          0xcd  
> >
> > Nitpick: I personally prefer uppercase hex numbers.
> >  
> 
> Noted.
> 
> > > +                  NAND_MEMORG(1, 2048, 64, 64, 1024, 20, 1, 1, 1),
> > > +                  NAND_ECCREQ(4, 512),
> > > +                  SPINAND_INFO_OP_VARIANTS(&read_cache_variants,
> > > +                                           &write_cache_variants,
> > > +                                           &update_cache_variants),  
> >
> > This device probably supports more variants (especially dual/quad
> > ones) but I guess it's not a problem to not have them here right now.  
> 
> Right now I can't really test dual or quad because my SPI driver
> doesn't know to do dual or quad io.
> I plan to add those in once I can validate they work.
> 
> > > +                  SPINAND_HAS_QE_BIT,
> > > +                  SPINAND_ECCINFO(NULL,
> > > +                                  NULL)),  
> >
> > You should define the ->ecc and ->free hooks of the
> > mtd_ooblayout_ops structure and point to it here. It defines the free
> > OOB bytes and bytes used by the on-die ECC engine. You should find this
> > in the datasheet. You may look at other manufacturer drivers for
> > examples of how it should be implemented. It is the way to tell the
> > upper layers that eg. "byte 2 to 17 are ECC bytes, 18 until the end are
> > free to use".  
> 
> Ok I'll add those in. Is there a way I can test that my implementation is right?
> I.e. is writing something, reading it back and checking if the data is
> correct a good enough test here?
> I don't really want to make it look like this flash is supported and
> break someone's data. :)

You may try to use flash_erase/nandwrite/nanddump from the mtd-utils
package. You may first use a dummy functions and declare the entire
zone free (except for the bad block marker at the beginning).

Then, you may write the entire OOB area in regular mode then read it in
raw mode (-n). Sometimes the ECC bytes are not visible, in this case it
may be worth trying writing the OOB area with known data and read it
back and see what you get. But these information probably are in the
datasheet.

Good luck,
Miquèl