On Tue, 2 Jun 2020 16:31:16 +0200 Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > Despite its current name "eccreq", this object first stores data that > is meant to be the requirements, and then this data gets eventually > updated and becomes the actual configuration. Despite its current name, the eccreq field actually encodes both the NAND requirements and the final ECC configuration. That works fine when using on-die ECC since those 2 concepts match perfectly, but it starts being a problem as soon as we use on-host ECC engines, where we're not guaranteed to have a perfect match. > Abstracting this > indirection will help us clarify the structures in a future change. Let's hide the ECC configuration access behind a helper so we can later split those 2 concepts. > > Signed-off-by: Miquel Raynal <miquel.raynal@xxxxxxxxxxx> > --- > include/linux/mtd/nand.h | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h > index 2f838394b5f7..7fd0d492073b 100644 > --- a/include/linux/mtd/nand.h > +++ b/include/linux/mtd/nand.h > @@ -512,6 +512,16 @@ nanddev_get_memorg(struct nand_device *nand) > return &nand->memorg; > } > > +/** > + * nanddev_get_ecc_conf() - Extract the ECC configuration from a NAND device > + * @nand: NAND device > + */ > +static inline const struct nand_ecc_props * > +nanddev_get_ecc_conf(struct nand_device *nand) > +{ > + return &nand->eccreq; > +} > + > int nanddev_init(struct nand_device *nand, const struct nand_ops *ops, > struct module *owner); > void nanddev_cleanup(struct nand_device *nand); ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/