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

[Miquel Raynal <miquel.raynal@xxxxxxxxxxx>]

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.


Thanks,
Miquèl

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