Messages in this thread | | | From | Daniel Palmer <> | Date | Tue, 5 Jan 2021 21:18:21 +0900 | Subject | Re: [PATCH 1/1] mtd: spinand: add support for Foresee FS35ND01G |
| |
Hi Miquel,
On Mon, 4 Jan 2021 at 23:17, Miquel Raynal <miquel.raynal@bootlin.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. :)
Thanks,
Daniel
| |