Re: [RFC PATCH 25/27] mtd: nand: Add helpers to manage ECC engines and configurationsND

[Boris Brezillon <boris.brezillon@xxxxxxxxxxxxx>]

On Tue, 26 Feb 2019 16:59:23 +0100
Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote:

> Hi Boris,
> 
> Boris Brezillon <boris.brezillon@xxxxxxxxxxxxx> wrote on Mon, 25 Feb
> 2019 19:48:03 +0100:
> 
> > > > Also, the parsing of the DT (in nand_ecc_read_user_conf()) gives me the
> > > > user ECC mode and algo, so I cannot let the raw NAND core (or a raw
> > > > NAND controller driver) or the SPI NAND core decide which mode is the
> > > > default if not provided by the user.      
> > > 
> > > Except this prop is optional in most cases, and the default value is
> > > not always the same, which is why I think this ECC engine retrieval step
> > > should be left to each sub-layer (and sometimes to the controller driver
> > > behind it). Maybe you can provide helpers to help with that, but I
> > > don't think taking this decision here, based on the bus type, is a good
> > > idea. And I also don't like the idea of adding a new SPINAND type.    
> > 
> > Hm, after thinking a bit more about it, maybe we could have something
> > in-between: let the controller driver or sub-layer specify what the
> > default values are (provider/mode and possibly algorithm if that makes
> > sense) so that this generic function can use these defaults when
> > nand->ecc.user_conf.{mode,algo} == UNKNOWN.  
> 
> Having a "default_provider" in struct nand_ecc could to the trick. It
> would be filled by the controller drivers/sublayers before
> nanddev_ecc_engine_init() is called.

You'll also need a default_algo, at least for SW ECC. Note that other
props, like strength, step-size or flags (like the maximize flag) can
be left undefined as well, so providing default vals for those ones (or
deriving them from ECC requirements) might make sense too.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/