Hi,
Den tors 24 jan. 2019 kl 16:28 skrev Stefan Roese <sr@xxxxxxx>:
>
> On 24.01.19 15:20, Boris Brezillon wrote:
> > Looks like PROGRAM LOAD (AKA write cache) does not necessarily reset
> > the cache content to 0xFF (depends on vendor implementation), so we
> > must fill the page cache entirely even if we only want to program the
> > data portion of the page, otherwise we might corrupt the BBM or user
> > data previously programmed in OOB area.
> >
> > Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs")
> > Reported-by: Stefan Roese <sr@xxxxxxx>
> > Cc: <stable@xxxxxxxxxxxxxxx>
> > Signed-off-by: Boris Brezillon <bbrezillon@xxxxxxxxxx>
>
> Works fine (limited testing only yet), so:
>
> Tested-by: Stefan Roese <sr@xxxxxxx>
> Reviewed-by: Stefan Roese <sr@xxxxxxx>
>
> Thanks,
> Stefan
>
Can this quirk be made vendor specific? It seems a waste of SPI
transfer cycles to write 0xff to the whole OOB area when we only want
to program the data area if the chip doesn't need this quirk.
For which logic is this needed anyway? According to the GigaDevice
datasheet, if a Program Load is followed by Program Execute,
"uninitialized" bytes will be set to 0xff, which is the flow that is
used by spinand core.
/Emil
