Re: [RESEND PATCH 2/5] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver

[Miquel Raynal]

Hi Stefan,

On Thu, 24 May 2018 14:19:18 +0200, Stefan Agner <stefan@xxxxxxxx>
wrote:

> On 24.05.2018 13:53, Boris Brezillon wrote:
> > Hi Benjamin,
> > 
> > On Thu, 24 May 2018 13:30:14 +0200
> > Benjamin Lindqvist <benjamin.lindqvist@xxxxxxxxx> wrote:
> >   
> >> Hi Stefan,
> >>
> >> It seems to me that a probe similar to what the BootROM does shouldn't
> >> be awfully complicated to implement - just cycle through the switch
> >> cases in case of an ECC error. But I guess that's more of an idea for
> >> further improvements rather than a comment to the patch set under
> >> review.  
> > 
> > Nope, not really an option, because you're not guaranteed that the NAND
> > will be used as a boot media, and the first page or first set of pages
> > might just be erased.
> >   
> 
> Yeah I did not meant probing like the Boot ROM does.
> 
> What I meant was using only the ECC modes which are supported by the
> Boot ROM when the driver tries to choose a viable mode. So that would
> be:
> - RS t=4
> - BCH t=8
> - BCH t=16
> 
> Maybe we could add a property to enable that behavior:
> 
> tegra,use-bootable-ecc-only;

I'm not sure a property is needed.

As there is currently no official user of this driver, why not turning
mandatory the nand-ecc-xxx properties? In the documentation you can add
a note saying that using other algorithms than the three above is not
supported by the BootROM.

> 
> >>
> >> However, I think that allowing for an override of the oobsize
> >> inference would be a good idea before merging, no? This could just be
> >> a trivial #ifdef (at least temporarily). If you agree but don't feel
> >> like doing it yourself, I'd be happy to pitch in. Let me know.  
> > 
> > That's why we have nand-ecc-xxx properties in the DT.
> >   
> 
> Yes, nand-ecc-strength is the first thing I plan to implement, that way
> strength can be defined in dt.
> 
> --
> Stefan

Thanks,
MiquÃl