Message ID | 20200603175759.19948-12-miquel.raynal@bootlin.com |
---|---|
State | Accepted |
Commit | d193792a26c216cb7db3cf12300c9414990fa603 |
Headers | show |
Series | Introduction of the generic ECC framework | expand |
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h index 8cf5bdbea782..9cbb41a5541c 100644 --- a/include/linux/mtd/nand.h +++ b/include/linux/mtd/nand.h @@ -523,6 +523,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);
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. 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@bootlin.com> --- include/linux/mtd/nand.h | 10 ++++++++++ 1 file changed, 10 insertions(+)