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/