From a2aec2c86ef0cad0fd6be718cfeb5cf5eefbfca9 Mon Sep 17 00:00:00 2001 From: "GONG, Ruiqi" Date: Mon, 30 Aug 2021 16:33:56 +0800 Subject: mtd: Remove obsolete macros only used by the old nand_ecclayout struct All uses of MTD_MAX_{OOBFREE,ECCPOS}_ENTRIES_LARGE have been removed as commit ef5eeea6e911 ("mtd: nand: brcm: switch to mtd_ooblayout_ops") and commit aab616e31d1c ("mtd: kill the nand_ecclayout struct") replaced struct nand_ecclayout by the new mtd_ooblayout_ops interface. Remove these two macros therefore. Reported-by: Yi Yang Signed-off-by: GONG, Ruiqi Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210830083356.31702-1-gongruiqi1@huawei.com --- include/linux/mtd/mtd.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h index 88227044fc86..f5e7dfc2e4e9 100644 --- a/include/linux/mtd/mtd.h +++ b/include/linux/mtd/mtd.h @@ -72,8 +72,6 @@ struct mtd_oob_ops { uint8_t *oobbuf; }; -#define MTD_MAX_OOBFREE_ENTRIES_LARGE 32 -#define MTD_MAX_ECCPOS_ENTRIES_LARGE 640 /** * struct mtd_oob_region - oob region definition * @offset: region offset -- cgit From c606d4f77c8a637c0563a206b080c5663f72b61a Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:40:30 +0800 Subject: mtd: rawnand: atmel: Make use of the helper function devm_platform_ioremap_resource() Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing Reviewed-by: Nicolas Ferre Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210901074031.8883-1-caihuoqing@baidu.com --- drivers/mtd/nand/raw/atmel/pmecc.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/mtd/nand/raw/atmel/pmecc.c b/drivers/mtd/nand/raw/atmel/pmecc.c index cbb023bf00f7..498e41ccabbd 100644 --- a/drivers/mtd/nand/raw/atmel/pmecc.c +++ b/drivers/mtd/nand/raw/atmel/pmecc.c @@ -834,7 +834,6 @@ static struct atmel_pmecc *atmel_pmecc_create(struct platform_device *pdev, { struct device *dev = &pdev->dev; struct atmel_pmecc *pmecc; - struct resource *res; pmecc = devm_kzalloc(dev, sizeof(*pmecc), GFP_KERNEL); if (!pmecc) @@ -844,13 +843,11 @@ static struct atmel_pmecc *atmel_pmecc_create(struct platform_device *pdev, pmecc->dev = dev; mutex_init(&pmecc->lock); - res = platform_get_resource(pdev, IORESOURCE_MEM, pmecc_res_idx); - pmecc->regs.base = devm_ioremap_resource(dev, res); + pmecc->regs.base = devm_platform_ioremap_resource(pdev, pmecc_res_idx); if (IS_ERR(pmecc->regs.base)) return ERR_CAST(pmecc->regs.base); - res = platform_get_resource(pdev, IORESOURCE_MEM, errloc_res_idx); - pmecc->regs.errloc = devm_ioremap_resource(dev, res); + pmecc->regs.errloc = devm_platform_ioremap_resource(pdev, errloc_res_idx); if (IS_ERR(pmecc->regs.errloc)) return ERR_CAST(pmecc->regs.errloc); -- cgit From df9e5170bc4d2d96a0c5dcfd3960c3e248a37218 Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:40:38 +0800 Subject: mtd: rawnand: bcm6368: Make use of the helper function devm_platform_ioremap_resource_byname() Use the devm_platform_ioremap_resource_byname() helper instead of calling platform_get_resource_byname() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210901074108.8933-1-caihuoqing@baidu.com --- drivers/mtd/nand/raw/brcmnand/bcm6368_nand.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/mtd/nand/raw/brcmnand/bcm6368_nand.c b/drivers/mtd/nand/raw/brcmnand/bcm6368_nand.c index 7c17ec4ce8b6..a06cd87f839a 100644 --- a/drivers/mtd/nand/raw/brcmnand/bcm6368_nand.c +++ b/drivers/mtd/nand/raw/brcmnand/bcm6368_nand.c @@ -88,16 +88,13 @@ static int bcm6368_nand_probe(struct platform_device *pdev) struct device *dev = &pdev->dev; struct bcm6368_nand_soc *priv; struct brcmnand_soc *soc; - struct resource *res; priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL); if (!priv) return -ENOMEM; soc = &priv->soc; - res = platform_get_resource_byname(pdev, - IORESOURCE_MEM, "nand-int-base"); - priv->base = devm_ioremap_resource(dev, res); + priv->base = devm_platform_ioremap_resource_byname(pdev, "nand-int-base"); if (IS_ERR(priv->base)) return PTR_ERR(priv->base); -- cgit From 5f14a8ca1b493a3c633ff549fb7d494887d7804a Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:41:15 +0800 Subject: mtd: rawnand: denali: Make use of the helper function devm_platform_ioremap_resource_byname() Use the devm_platform_ioremap_resource_byname() helper instead of calling platform_get_resource_byname() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210901074116.8983-1-caihuoqing@baidu.com --- drivers/mtd/nand/raw/denali_dt.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/mtd/nand/raw/denali_dt.c b/drivers/mtd/nand/raw/denali_dt.c index f08740ae282b..8513bb9fcfcc 100644 --- a/drivers/mtd/nand/raw/denali_dt.c +++ b/drivers/mtd/nand/raw/denali_dt.c @@ -113,7 +113,6 @@ static int denali_dt_chip_init(struct denali_controller *denali, static int denali_dt_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; - struct resource *res; struct denali_dt *dt; const struct denali_dt_data *data; struct denali_controller *denali; @@ -139,13 +138,11 @@ static int denali_dt_probe(struct platform_device *pdev) if (denali->irq < 0) return denali->irq; - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "denali_reg"); - denali->reg = devm_ioremap_resource(dev, res); + denali->reg = devm_platform_ioremap_resource_byname(pdev, "denali_reg"); if (IS_ERR(denali->reg)) return PTR_ERR(denali->reg); - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nand_data"); - denali->host = devm_ioremap_resource(dev, res); + denali->host = devm_platform_ioremap_resource_byname(pdev, "nand_data"); if (IS_ERR(denali->host)) return PTR_ERR(denali->host); -- cgit From 557de1cfabd6ea5476e5364a00d23d26bdfa3d4d Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:41:22 +0800 Subject: mtd: rawnand: gpio: Make use of the helper function devm_platform_ioremap_resource() Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210901074123.9033-1-caihuoqing@baidu.com --- drivers/mtd/nand/raw/gpio.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/mtd/nand/raw/gpio.c b/drivers/mtd/nand/raw/gpio.c index fb7a086de35e..8901c4aa0c21 100644 --- a/drivers/mtd/nand/raw/gpio.c +++ b/drivers/mtd/nand/raw/gpio.c @@ -303,8 +303,7 @@ static int gpio_nand_probe(struct platform_device *pdev) chip = &gpiomtd->nand_chip; - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - gpiomtd->io = devm_ioremap_resource(dev, res); + gpiomtd->io = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(gpiomtd->io)) return PTR_ERR(gpiomtd->io); -- cgit From fe6b7a9f9159a3a55f5227e03c97f65b4d81dc71 Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:41:30 +0800 Subject: mtd: rawnand: gpmi: Make use of the helper function devm_platform_ioremap_resource_byname() Use the devm_platform_ioremap_resource_byname() helper instead of calling platform_get_resource_byname() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210901074130.9083-1-caihuoqing@baidu.com --- drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c index 4d08e4ab5c1b..10cc71829dcb 100644 --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c @@ -951,11 +951,9 @@ static int acquire_register_block(struct gpmi_nand_data *this, { struct platform_device *pdev = this->pdev; struct resources *res = &this->resources; - struct resource *r; void __iomem *p; - r = platform_get_resource_byname(pdev, IORESOURCE_MEM, res_name); - p = devm_ioremap_resource(&pdev->dev, r); + p = devm_platform_ioremap_resource_byname(pdev, res_name); if (IS_ERR(p)) return PTR_ERR(p); -- cgit From 1cda2633999a9431bc00d7881e2ea96cff5da22f Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:41:37 +0800 Subject: mtd: rawnand: hisi504: Make use of the helper function devm_platform_ioremap_resource() Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210901074138.9133-1-caihuoqing@baidu.com --- drivers/mtd/nand/raw/hisi504_nand.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/mtd/nand/raw/hisi504_nand.c b/drivers/mtd/nand/raw/hisi504_nand.c index 78c4e05434e2..c74f6b2192fc 100644 --- a/drivers/mtd/nand/raw/hisi504_nand.c +++ b/drivers/mtd/nand/raw/hisi504_nand.c @@ -738,7 +738,6 @@ static int hisi_nfc_probe(struct platform_device *pdev) struct hinfc_host *host; struct nand_chip *chip; struct mtd_info *mtd; - struct resource *res; struct device_node *np = dev->of_node; host = devm_kzalloc(dev, sizeof(*host), GFP_KERNEL); @@ -754,13 +753,11 @@ static int hisi_nfc_probe(struct platform_device *pdev) if (irq < 0) return -ENXIO; - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - host->iobase = devm_ioremap_resource(dev, res); + host->iobase = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(host->iobase)) return PTR_ERR(host->iobase); - res = platform_get_resource(pdev, IORESOURCE_MEM, 1); - host->mmio = devm_ioremap_resource(dev, res); + host->mmio = devm_platform_ioremap_resource(pdev, 1); if (IS_ERR(host->mmio)) return PTR_ERR(host->mmio); -- cgit From 5da7bb27a582b8f232c09dd1067eb7a254c4d4ee Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:41:44 +0800 Subject: mtd: rawnand: mtk: Make use of the helper function devm_platform_ioremap_resource() Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210901074145.9183-1-caihuoqing@baidu.com --- drivers/mtd/nand/raw/mtk_nand.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/mtk_nand.c b/drivers/mtd/nand/raw/mtk_nand.c index 5c5c92132287..66f04c693c87 100644 --- a/drivers/mtd/nand/raw/mtk_nand.c +++ b/drivers/mtd/nand/raw/mtk_nand.c @@ -1520,7 +1520,6 @@ static int mtk_nfc_probe(struct platform_device *pdev) struct device *dev = &pdev->dev; struct device_node *np = dev->of_node; struct mtk_nfc *nfc; - struct resource *res; int ret, irq; nfc = devm_kzalloc(dev, sizeof(*nfc), GFP_KERNEL); @@ -1541,8 +1540,7 @@ static int mtk_nfc_probe(struct platform_device *pdev) nfc->caps = of_device_get_match_data(dev); nfc->dev = dev; - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - nfc->regs = devm_ioremap_resource(dev, res); + nfc->regs = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(nfc->regs)) { ret = PTR_ERR(nfc->regs); goto release_ecc; -- cgit From 8826e1107236d8668cfbcf8b31caea3ac943de1e Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:41:52 +0800 Subject: mtd: rawnand: mtk_ecc: Make use of the helper function devm_platform_ioremap_resource() Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210901074153.9233-1-caihuoqing@baidu.com --- drivers/mtd/nand/raw/mtk_ecc.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/mtk_ecc.c b/drivers/mtd/nand/raw/mtk_ecc.c index c437d97debb8..1b47964cb6da 100644 --- a/drivers/mtd/nand/raw/mtk_ecc.c +++ b/drivers/mtd/nand/raw/mtk_ecc.c @@ -495,7 +495,6 @@ static int mtk_ecc_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; struct mtk_ecc *ecc; - struct resource *res; u32 max_eccdata_size; int irq, ret; @@ -513,8 +512,7 @@ static int mtk_ecc_probe(struct platform_device *pdev) if (!ecc->eccdata) return -ENOMEM; - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - ecc->regs = devm_ioremap_resource(dev, res); + ecc->regs = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(ecc->regs)) return PTR_ERR(ecc->regs); -- cgit From 7b7be21861819afcc0b82cd6f0fe5baef40374cd Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:41:59 +0800 Subject: mtd: rawnand: omap_elm: Make use of the helper function devm_platform_ioremap_resource() Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210901074200.9283-1-caihuoqing@baidu.com --- drivers/mtd/nand/raw/omap_elm.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/omap_elm.c b/drivers/mtd/nand/raw/omap_elm.c index 2b21ce04b3ec..8bab753211e9 100644 --- a/drivers/mtd/nand/raw/omap_elm.c +++ b/drivers/mtd/nand/raw/omap_elm.c @@ -384,7 +384,7 @@ static irqreturn_t elm_isr(int this_irq, void *dev_id) static int elm_probe(struct platform_device *pdev) { int ret = 0; - struct resource *res, *irq; + struct resource *irq; struct elm_info *info; info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL); @@ -399,8 +399,7 @@ static int elm_probe(struct platform_device *pdev) return -ENODEV; } - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - info->elm_base = devm_ioremap_resource(&pdev->dev, res); + info->elm_base = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(info->elm_base)) return PTR_ERR(info->elm_base); -- cgit From f47dca43c51f6d1fa0cc1574badc748724d9286c Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:42:07 +0800 Subject: mtd: rawnand: oxnas: Make use of the helper function devm_platform_ioremap_resource() Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing Reviewed-by: Neil Armstrong Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210901074207.9333-1-caihuoqing@baidu.com --- drivers/mtd/nand/raw/oxnas_nand.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/oxnas_nand.c b/drivers/mtd/nand/raw/oxnas_nand.c index f44947043e5a..cd112d45e0b5 100644 --- a/drivers/mtd/nand/raw/oxnas_nand.c +++ b/drivers/mtd/nand/raw/oxnas_nand.c @@ -79,7 +79,6 @@ static int oxnas_nand_probe(struct platform_device *pdev) struct oxnas_nand_ctrl *oxnas; struct nand_chip *chip; struct mtd_info *mtd; - struct resource *res; int count = 0; int err = 0; int i; @@ -92,8 +91,7 @@ static int oxnas_nand_probe(struct platform_device *pdev) nand_controller_init(&oxnas->base); - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - oxnas->io_base = devm_ioremap_resource(&pdev->dev, res); + oxnas->io_base = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(oxnas->io_base)) return PTR_ERR(oxnas->io_base); -- cgit From 7e2561430dff0a1bb9ab794e70fcaa56852e10f9 Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:42:14 +0800 Subject: mtd: rawnand: plat_nand: Make use of the helper function devm_platform_ioremap_resource() Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210901074215.9383-1-caihuoqing@baidu.com --- drivers/mtd/nand/raw/plat_nand.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/plat_nand.c b/drivers/mtd/nand/raw/plat_nand.c index 7711e1020c21..c1b2072cb507 100644 --- a/drivers/mtd/nand/raw/plat_nand.c +++ b/drivers/mtd/nand/raw/plat_nand.c @@ -41,7 +41,6 @@ static int plat_nand_probe(struct platform_device *pdev) struct platform_nand_data *pdata = dev_get_platdata(&pdev->dev); struct plat_nand_data *data; struct mtd_info *mtd; - struct resource *res; const char **part_types; int err = 0; @@ -65,8 +64,7 @@ static int plat_nand_probe(struct platform_device *pdev) nand_controller_init(&data->controller); data->chip.controller = &data->controller; - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - data->io_base = devm_ioremap_resource(&pdev->dev, res); + data->io_base = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(data->io_base)) return PTR_ERR(data->io_base); -- cgit From 8d77c55f090def05f450df8aa6ee16ec6f4d01ba Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:42:22 +0800 Subject: mtd: rawnand: stm32_fmc2: Make use of the helper function devm_platform_ioremap_resource() Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing Reviewed-by: Christophe Kerello Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210901074222.9433-1-caihuoqing@baidu.com --- drivers/mtd/nand/raw/stm32_fmc2_nand.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/mtd/nand/raw/stm32_fmc2_nand.c b/drivers/mtd/nand/raw/stm32_fmc2_nand.c index 1c277fbb91f2..97b4e02e43e4 100644 --- a/drivers/mtd/nand/raw/stm32_fmc2_nand.c +++ b/drivers/mtd/nand/raw/stm32_fmc2_nand.c @@ -1899,15 +1899,11 @@ static int stm32_fmc2_nfc_probe(struct platform_device *pdev) nfc->data_phys_addr[chip_cs] = res->start; - res = platform_get_resource(pdev, IORESOURCE_MEM, - mem_region + 1); - nfc->cmd_base[chip_cs] = devm_ioremap_resource(dev, res); + nfc->cmd_base[chip_cs] = devm_platform_ioremap_resource(pdev, mem_region + 1); if (IS_ERR(nfc->cmd_base[chip_cs])) return PTR_ERR(nfc->cmd_base[chip_cs]); - res = platform_get_resource(pdev, IORESOURCE_MEM, - mem_region + 2); - nfc->addr_base[chip_cs] = devm_ioremap_resource(dev, res); + nfc->addr_base[chip_cs] = devm_platform_ioremap_resource(pdev, mem_region + 2); if (IS_ERR(nfc->addr_base[chip_cs])) return PTR_ERR(nfc->addr_base[chip_cs]); } -- cgit From 2f597bc45e47e245e30265de8494423c3a1a7900 Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:42:29 +0800 Subject: mtd: rawnand: tegra: Make use of the helper function devm_platform_ioremap_resource() Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing Acked-by: Stefan Agner Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210901074230.9483-1-caihuoqing@baidu.com --- drivers/mtd/nand/raw/tegra_nand.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/tegra_nand.c b/drivers/mtd/nand/raw/tegra_nand.c index fbf67722a049..32431bbe69b8 100644 --- a/drivers/mtd/nand/raw/tegra_nand.c +++ b/drivers/mtd/nand/raw/tegra_nand.c @@ -1144,7 +1144,6 @@ static int tegra_nand_probe(struct platform_device *pdev) { struct reset_control *rst; struct tegra_nand_controller *ctrl; - struct resource *res; int err = 0; ctrl = devm_kzalloc(&pdev->dev, sizeof(*ctrl), GFP_KERNEL); @@ -1155,8 +1154,7 @@ static int tegra_nand_probe(struct platform_device *pdev) nand_controller_init(&ctrl->controller); ctrl->controller.ops = &tegra_nand_controller_ops; - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - ctrl->regs = devm_ioremap_resource(&pdev->dev, res); + ctrl->regs = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(ctrl->regs)) return PTR_ERR(ctrl->regs); -- cgit From 524bd02a6ff8c25a88077747020c1d0a7a94594b Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:42:37 +0800 Subject: mtd: rawnand: txx9ndfm: Make use of the helper function devm_platform_ioremap_resource() Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210901074237.9533-1-caihuoqing@baidu.com --- drivers/mtd/nand/raw/txx9ndfmc.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/txx9ndfmc.c b/drivers/mtd/nand/raw/txx9ndfmc.c index b8894ac27073..b42d61b30c0b 100644 --- a/drivers/mtd/nand/raw/txx9ndfmc.c +++ b/drivers/mtd/nand/raw/txx9ndfmc.c @@ -284,13 +284,11 @@ static int __init txx9ndfmc_probe(struct platform_device *dev) int i; struct txx9ndfmc_drvdata *drvdata; unsigned long gbusclk = plat->gbus_clock; - struct resource *res; drvdata = devm_kzalloc(&dev->dev, sizeof(*drvdata), GFP_KERNEL); if (!drvdata) return -ENOMEM; - res = platform_get_resource(dev, IORESOURCE_MEM, 0); - drvdata->base = devm_ioremap_resource(&dev->dev, res); + drvdata->base = devm_platform_ioremap_resource(dev, 0); if (IS_ERR(drvdata->base)) return PTR_ERR(drvdata->base); -- cgit From 2d77b08eaf0b2f269512c200c441bb1cda59d978 Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:42:44 +0800 Subject: mtd: rawnand: vf610: Make use of the helper function devm_platform_ioremap_resource() Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing Acked-by: Stefan Agner Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210901074245.9583-1-caihuoqing@baidu.com --- drivers/mtd/nand/raw/vf610_nfc.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/vf610_nfc.c b/drivers/mtd/nand/raw/vf610_nfc.c index 40d70f991d89..a2b89b75073f 100644 --- a/drivers/mtd/nand/raw/vf610_nfc.c +++ b/drivers/mtd/nand/raw/vf610_nfc.c @@ -807,7 +807,6 @@ static const struct nand_controller_ops vf610_nfc_controller_ops = { static int vf610_nfc_probe(struct platform_device *pdev) { struct vf610_nfc *nfc; - struct resource *res; struct mtd_info *mtd; struct nand_chip *chip; struct device_node *child; @@ -831,8 +830,7 @@ static int vf610_nfc_probe(struct platform_device *pdev) if (irq <= 0) return -EINVAL; - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - nfc->regs = devm_ioremap_resource(nfc->dev, res); + nfc->regs = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(nfc->regs)) return PTR_ERR(nfc->regs); -- cgit From abac656349cb9f081bc3b0a4c75d98486ade77f0 Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:42:51 +0800 Subject: mtd: rawnand: xway: Make use of the helper function devm_platform_ioremap_resource() Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210901074252.9633-1-caihuoqing@baidu.com --- drivers/mtd/nand/raw/xway_nand.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/xway_nand.c b/drivers/mtd/nand/raw/xway_nand.c index 26751976e502..92067bd55384 100644 --- a/drivers/mtd/nand/raw/xway_nand.c +++ b/drivers/mtd/nand/raw/xway_nand.c @@ -167,7 +167,6 @@ static int xway_nand_probe(struct platform_device *pdev) { struct xway_nand_data *data; struct mtd_info *mtd; - struct resource *res; int err; u32 cs; u32 cs_flag = 0; @@ -178,8 +177,7 @@ static int xway_nand_probe(struct platform_device *pdev) if (!data) return -ENOMEM; - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - data->nandaddr = devm_ioremap_resource(&pdev->dev, res); + data->nandaddr = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(data->nandaddr)) return PTR_ERR(data->nandaddr); -- cgit From 46a0dc10fb32bec3e765e51bf71fbc070dc77ca3 Mon Sep 17 00:00:00 2001 From: Evgeny Novikov Date: Fri, 3 Sep 2021 11:26:53 +0300 Subject: mtd: rawnand: intel: Fix potential buffer overflow in probe ebu_nand_probe() read the value of u32 variable "cs" from the device firmware description and used it as the index for array ebu_host->cs that can contain MAX_CS (2) elements at most. That could result in a buffer overflow and various bad consequences later. Fix the potential buffer overflow by restricting values of "cs" with MAX_CS in probe. Found by Linux Driver Verification project (linuxtesting.org). Fixes: 0b1039f016e8 ("mtd: rawnand: Add NAND controller support on Intel LGM SoC") Signed-off-by: Evgeny Novikov Co-developed-by: Kirill Shilimanov Signed-off-by: Kirill Shilimanov Co-developed-by: Anton Vasilyev Signed-off-by: Anton Vasilyev Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210903082653.16441-1-novikov@ispras.ru --- drivers/mtd/nand/raw/intel-nand-controller.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/mtd/nand/raw/intel-nand-controller.c b/drivers/mtd/nand/raw/intel-nand-controller.c index b9784f3da7a1..7c1c80dae826 100644 --- a/drivers/mtd/nand/raw/intel-nand-controller.c +++ b/drivers/mtd/nand/raw/intel-nand-controller.c @@ -609,6 +609,11 @@ static int ebu_nand_probe(struct platform_device *pdev) dev_err(dev, "failed to get chip select: %d\n", ret); return ret; } + if (cs >= MAX_CS) { + dev_err(dev, "got invalid chip select: %d\n", cs); + return -EINVAL; + } + ebu_host->cs_num = cs; resname = devm_kasprintf(dev, GFP_KERNEL, "nand_cs%d", cs); -- cgit From b72841e4dcd54de486fca2e4ffa00b8defc1eecc Mon Sep 17 00:00:00 2001 From: Colin Ian King Date: Fri, 10 Sep 2021 13:00:23 +0100 Subject: mtd: mtdswap: Remove redundant assignment of pointer eb The pointer eb is being assigned a value that is never read, it is being updated later on. The assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210910120023.46308-1-colin.king@canonical.com --- drivers/mtd/mtdswap.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/mtd/mtdswap.c b/drivers/mtd/mtdswap.c index 7e309270ddd4..e86b04bc1d6b 100644 --- a/drivers/mtd/mtdswap.c +++ b/drivers/mtd/mtdswap.c @@ -716,7 +716,6 @@ retry: return ret; } - eb = d->eb_data + *newblock / d->pages_per_eblk; d->page_data[page] = *newblock; d->revmap[oldblock] = PAGE_UNDEF; eb = d->eb_data + oldblock / d->pages_per_eblk; -- cgit From c2606ddcf5ad1969ceffe3c98d427b272243e150 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Fri, 24 Sep 2021 15:32:23 +0200 Subject: mtd: onenand: samsung: drop Exynos4 and describe driver in KConfig None of supported Samsung Exynos4 SoCs (Exynos4210, Exynos4412) seem to use OneNAND driver so drop it. Describe better which driver applies to which SoC, to make configuring kernel for Samsung SoC easier. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210924133223.111930-1-krzysztof.kozlowski@canonical.com --- drivers/mtd/nand/onenand/Kconfig | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/mtd/nand/onenand/Kconfig b/drivers/mtd/nand/onenand/Kconfig index 1a0e65bc246e..34d9a7a82ad4 100644 --- a/drivers/mtd/nand/onenand/Kconfig +++ b/drivers/mtd/nand/onenand/Kconfig @@ -33,11 +33,12 @@ config MTD_ONENAND_OMAP2 config MTD_ONENAND_SAMSUNG tristate "OneNAND on Samsung SOC controller support" - depends on ARCH_S3C64XX || ARCH_S5PV210 || ARCH_EXYNOS4 || COMPILE_TEST + depends on ARCH_S3C64XX || ARCH_S5PV210 || COMPILE_TEST help - Support for a OneNAND flash device connected to an Samsung SOC. - S3C64XX uses command mapping method. - S5PC110/S5PC210 use generic OneNAND method. + Support for a OneNAND flash device connected to Samsung S3C64XX + (using command mapping method) and S5PC110/S5PC210 (using generic + OneNAND method) SoCs. + Choose Y here only if you build for such Samsung SoC. config MTD_ONENAND_OTP bool "OneNAND OTP Support" -- cgit From 3f491d11d8cbc3e4b4ff67bfc7f065e1cb56bcef Mon Sep 17 00:00:00 2001 From: Pratyush Yadav Date: Fri, 24 Sep 2021 00:40:26 +0530 Subject: MAINTAINERS: Add spi-nor device tree binding under SPI NOR maintainers The binding is for the SPI NOR subsystem so the patches should be sent to its maintainers. Currently the patches get sent to Rob Herring and MTD maintainers who might not always have the full picture. Signed-off-by: Pratyush Yadav Signed-off-by: Tudor Ambarus Link: https://lore.kernel.org/r/20210923191026.19184-1-p.yadav@ti.com --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index abdcbcfef73d..3913d1114324 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -17652,6 +17652,7 @@ W: http://www.linux-mtd.infradead.org/ Q: http://patchwork.ozlabs.org/project/linux-mtd/list/ C: irc://irc.oftc.net/mtd T: git git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-nor/next +F: Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml F: drivers/mtd/spi-nor/ F: include/linux/mtd/spi-nor.h -- cgit From 15b02050baeebcf1a1a1d3146ddea8f37ae00f96 Mon Sep 17 00:00:00 2001 From: Jonathan Lemon Date: Mon, 28 Jun 2021 14:17:29 -0700 Subject: mtd: spi-nor: Enable locking for n25q128a13 As 4bit block protection patchset for some micron models are merged, n25q128a13 also uses 4 bit Block Protection scheme, so enable locking for it. Tested it on n25q128a13, the locking functions work well. Signed-off-by: Jonathan Lemon Signed-off-by: Tudor Ambarus Reviewed-by: Michael Walle Link: https://lore.kernel.org/r/20210628211729.3625017-1-jonathan.lemon@gmail.com --- drivers/mtd/spi-nor/micron-st.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/spi-nor/micron-st.c b/drivers/mtd/spi-nor/micron-st.c index c224e59820a1..f3d19b716b7b 100644 --- a/drivers/mtd/spi-nor/micron-st.c +++ b/drivers/mtd/spi-nor/micron-st.c @@ -146,7 +146,9 @@ static const struct flash_info st_parts[] = { SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_4BIT_BP | SPI_NOR_BP3_SR_BIT6) }, { "n25q128a13", INFO(0x20ba18, 0, 64 * 1024, 256, - SECT_4K | USE_FSR | SPI_NOR_QUAD_READ) }, + SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | + SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | + SPI_NOR_4BIT_BP | SPI_NOR_BP3_SR_BIT6) }, { "mt25ql256a", INFO6(0x20ba19, 0x104400, 64 * 1024, 512, SECT_4K | USE_FSR | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) }, -- cgit From 78e4d342187625585932bb437ec26e1060f7fc6f Mon Sep 17 00:00:00 2001 From: Evgeny Novikov Date: Fri, 9 Jul 2021 17:45:29 +0300 Subject: mtd: spi-nor: hisi-sfc: Remove excessive clk_disable_unprepare() hisi_spi_nor_probe() invokes clk_disable_unprepare() on all paths after successful call of clk_prepare_enable(). Besides, the clock is enabled by hispi_spi_nor_prep() and disabled by hispi_spi_nor_unprep(). So at remove time it is not possible to have the clock enabled. The patch removes excessive clk_disable_unprepare() from hisi_spi_nor_remove(). Found by Linux Driver Verification project (linuxtesting.org). Fixes: e523f11141bd ("mtd: spi-nor: add hisilicon spi-nor flash controller driver") Signed-off-by: Evgeny Novikov Signed-off-by: Tudor Ambarus Reviewed-by: Pratyush Yadav Link: https://lore.kernel.org/r/20210709144529.31379-1-novikov@ispras.ru --- drivers/mtd/spi-nor/controllers/hisi-sfc.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/mtd/spi-nor/controllers/hisi-sfc.c b/drivers/mtd/spi-nor/controllers/hisi-sfc.c index 47fbf1d1e557..516e50269478 100644 --- a/drivers/mtd/spi-nor/controllers/hisi-sfc.c +++ b/drivers/mtd/spi-nor/controllers/hisi-sfc.c @@ -477,7 +477,6 @@ static int hisi_spi_nor_remove(struct platform_device *pdev) hisi_spi_nor_unregister_all(host); mutex_destroy(&host->lock); - clk_disable_unprepare(host->clk); return 0; } -- cgit From a10ed4c42533362a825be2adb2e5272d3644553e Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:42:59 +0800 Subject: mtd: spi-nor: hisi-sfc: Make use of the helper function devm_platform_ioremap_resource_byname() Use the devm_platform_ioremap_resource_byname() helper instead of calling platform_get_resource_byname() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing Signed-off-by: Tudor Ambarus Acked-by: Pratyush Yadav Link: https://lore.kernel.org/r/20210901074259.9683-1-caihuoqing@baidu.com --- drivers/mtd/spi-nor/controllers/hisi-sfc.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/mtd/spi-nor/controllers/hisi-sfc.c b/drivers/mtd/spi-nor/controllers/hisi-sfc.c index 516e50269478..94a969185ceb 100644 --- a/drivers/mtd/spi-nor/controllers/hisi-sfc.c +++ b/drivers/mtd/spi-nor/controllers/hisi-sfc.c @@ -421,7 +421,6 @@ fail: static int hisi_spi_nor_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; - struct resource *res; struct hifmc_host *host; int ret; @@ -432,13 +431,11 @@ static int hisi_spi_nor_probe(struct platform_device *pdev) platform_set_drvdata(pdev, host); host->dev = dev; - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "control"); - host->regbase = devm_ioremap_resource(dev, res); + host->regbase = devm_platform_ioremap_resource_byname(pdev, "control"); if (IS_ERR(host->regbase)) return PTR_ERR(host->regbase); - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "memory"); - host->iobase = devm_ioremap_resource(dev, res); + host->iobase = devm_platform_ioremap_resource_byname(pdev, "memory"); if (IS_ERR(host->iobase)) return PTR_ERR(host->iobase); -- cgit From df872ab1ffe4bd865dfb5956cae4901429004ab6 Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:43:06 +0800 Subject: mtd: spi-nor: nxp-spifi: Make use of the helper function devm_platform_ioremap_resource_byname() Use the devm_platform_ioremap_resource_byname() helper instead of calling platform_get_resource_byname() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing Signed-off-by: Tudor Ambarus Acked-by: Pratyush Yadav Link: https://lore.kernel.org/r/20210901074307.9733-1-caihuoqing@baidu.com --- drivers/mtd/spi-nor/controllers/nxp-spifi.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/mtd/spi-nor/controllers/nxp-spifi.c b/drivers/mtd/spi-nor/controllers/nxp-spifi.c index 2635c80231bb..9032b9ab2eaf 100644 --- a/drivers/mtd/spi-nor/controllers/nxp-spifi.c +++ b/drivers/mtd/spi-nor/controllers/nxp-spifi.c @@ -381,20 +381,17 @@ static int nxp_spifi_probe(struct platform_device *pdev) { struct device_node *flash_np; struct nxp_spifi *spifi; - struct resource *res; int ret; spifi = devm_kzalloc(&pdev->dev, sizeof(*spifi), GFP_KERNEL); if (!spifi) return -ENOMEM; - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "spifi"); - spifi->io_base = devm_ioremap_resource(&pdev->dev, res); + spifi->io_base = devm_platform_ioremap_resource_byname(pdev, "spifi"); if (IS_ERR(spifi->io_base)) return PTR_ERR(spifi->io_base); - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "flash"); - spifi->flash_base = devm_ioremap_resource(&pdev->dev, res); + spifi->flash_base = devm_platform_ioremap_resource_byname(pdev, "flash"); if (IS_ERR(spifi->flash_base)) return PTR_ERR(spifi->flash_base); -- cgit From 9be1446ece291a1f08164bd056bed3d698681f8b Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:15:00 +0200 Subject: mtd: rawnand: fsmc: Fix use of SM ORDER The introduction of the generic ECC engine API lead to a number of changes in various drivers which broke some of them. Here is a typical example: I expected the SM_ORDER option to be handled by the Hamming ECC engine internals. Problem: the fsmc driver does not instantiate (yet) a real ECC engine object so we had to use a 'bare' ECC helper instead of the shiny rawnand functions. However, when not intializing this engine properly and using the bare helpers, we do not get the SM ORDER feature handled automatically. It looks like this was lost in the process so let's ensure we use the right SM ORDER now. Fixes: ad9ffdce4539 ("mtd: rawnand: fsmc: Fix external use of SW Hamming ECC helper") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210928221507.199198-2-miquel.raynal@bootlin.com --- drivers/mtd/nand/raw/fsmc_nand.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/fsmc_nand.c b/drivers/mtd/nand/raw/fsmc_nand.c index a3e66155ae40..658f0cbe7ce8 100644 --- a/drivers/mtd/nand/raw/fsmc_nand.c +++ b/drivers/mtd/nand/raw/fsmc_nand.c @@ -438,8 +438,10 @@ static int fsmc_correct_ecc1(struct nand_chip *chip, unsigned char *read_ecc, unsigned char *calc_ecc) { + bool sm_order = chip->ecc.options & NAND_ECC_SOFT_HAMMING_SM_ORDER; + return ecc_sw_hamming_correct(buf, read_ecc, calc_ecc, - chip->ecc.size, false); + chip->ecc.size, sm_order); } /* Count the number of 0's in buff upto a max of max_bits */ -- cgit From d8467112d645ec56760c78928e1e5a3f6faa9b74 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:15:01 +0200 Subject: mtd: rawnand: Let callers use the bare Hamming helpers Before the introduction of the ECC framework infrastructure, many drivers used the ->calculate/correct() Hamming helpers directly. The point of this framework was to avoid this kind of hackish calls and use a proper and generic API but it is true that in certain cases, drivers still need to use these helpers in order to do ECC computations on behalf of their limited hardware. Right after the introduction of the ECC engine core introduction, it was spotted that it was not possible to use the shiny rawnand software ECC helpers so easily because an ECC engine object should have been allocated and initialized first. While this works well in most cases, for these drivers just leveraging the power of a single helper in conjunction with some pretty old and limited hardware, it did not fit. The idea back then was to declare intermediate helpers which would make use of the exported software ECC engine bare functions while keeping the rawnand layer compatibility. As there was already functions with the rawnand_sw_hamming_ prefix it was decided to declare new local helpers for this purpose in each driver needing one. Besides being far from optimal, this design choice was blamed by Linus when he pulled the "fixes" pull request [1] so that is why now it is time to clean this mess up. Enhancing the implementation of the rawnand_ecc_sw_* helpers to support both cases, when the ECC object is instantiated and when it is not is a quite elegant way to solve this situation. This way, we can still use the existing and exported rawnand helpers while avoiding the need for each driver to declare its own helper. Following this change, most of the fixes sent in [2] can now be safely reverted. Only the fsmc fix will need to be kept because there is actually something specific to the driver to do in its ->correct() helper. [1] https://lore.kernel.org/lkml/CAHk-=wh_ZHF685Fni8V9is17mj=pFisUaZ_0=gq6nbK+ZcyQmg@mail.gmail.com/ [2] https://lore.kernel.org/linux-mtd/20210413161840.345208-1-miquel.raynal@bootlin.com/ Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210928221507.199198-3-miquel.raynal@bootlin.com --- drivers/mtd/nand/ecc-sw-hamming.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/ecc-sw-hamming.c b/drivers/mtd/nand/ecc-sw-hamming.c index a7655b668f32..254db2e7f8bb 100644 --- a/drivers/mtd/nand/ecc-sw-hamming.c +++ b/drivers/mtd/nand/ecc-sw-hamming.c @@ -364,9 +364,9 @@ int nand_ecc_sw_hamming_calculate(struct nand_device *nand, { struct nand_ecc_sw_hamming_conf *engine_conf = nand->ecc.ctx.priv; unsigned int step_size = nand->ecc.ctx.conf.step_size; + bool sm_order = engine_conf ? engine_conf->sm_order : false; - return ecc_sw_hamming_calculate(buf, step_size, code, - engine_conf->sm_order); + return ecc_sw_hamming_calculate(buf, step_size, code, sm_order); } EXPORT_SYMBOL(nand_ecc_sw_hamming_calculate); @@ -457,9 +457,10 @@ int nand_ecc_sw_hamming_correct(struct nand_device *nand, unsigned char *buf, { struct nand_ecc_sw_hamming_conf *engine_conf = nand->ecc.ctx.priv; unsigned int step_size = nand->ecc.ctx.conf.step_size; + bool sm_order = engine_conf ? engine_conf->sm_order : false; return ecc_sw_hamming_correct(buf, read_ecc, calc_ecc, step_size, - engine_conf->sm_order); + sm_order); } EXPORT_SYMBOL(nand_ecc_sw_hamming_correct); -- cgit From e7f466c51ce9179a7b5105f93fdb3e85ef6b61ce Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:15:02 +0200 Subject: Revert "mtd: rawnand: txx9ndfmc: Fix external use of SW Hamming ECC helper" This reverts commit 3d227a0b0ce319edbff6fd0d8af4d66689e477cc. Before the introduction of the ECC framework infrastructure, many drivers used the ->calculate/correct() Hamming helpers directly. The point of this framework was to avoid this kind of hackish calls and use a proper and generic API but it is true that in certain cases, drivers still need to use these helpers in order to do ECC computations on behalf of their limited hardware. Right after the introduction of the ECC engine core introduction, it was spotted that it was not possible to use the shiny rawnand software ECC helpers so easily because an ECC engine object should have been allocated and initialized first. While this works well in most cases, for these drivers just leveraging the power of a single helper in conjunction with some pretty old and limited hardware, it did not fit. The idea back then was to declare intermediate helpers which would make use of the exported software ECC engine bare functions while keeping the rawnand layer compatibility. As there was already functions with the rawnand_sw_hamming_ prefix it was decided to declare new local helpers for this purpose in each driver needing one. Besides being far from optimal, this design choice was blamed by Linus when he pulled the "fixes" pull request [1] so that is why now it is time to clean this mess up. The implementation of the rawnand_ecc_sw_* helpers has now been enhanced to support both cases, when the ECC object is instantiated and when it is not. This way, we can still use the existing and exported rawnand helpers while avoiding the need for each driver to declare its own helper, thus this fix from [2] can now be safely reverted. [1] https://lore.kernel.org/lkml/CAHk-=wh_ZHF685Fni8V9is17mj=pFisUaZ_0=gq6nbK+ZcyQmg@mail.gmail.com/ [2] https://lore.kernel.org/linux-mtd/20210413161840.345208-1-miquel.raynal@bootlin.com Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210928221507.199198-4-miquel.raynal@bootlin.com --- drivers/mtd/nand/raw/txx9ndfmc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/txx9ndfmc.c b/drivers/mtd/nand/raw/txx9ndfmc.c index b42d61b30c0b..eddcc0728a67 100644 --- a/drivers/mtd/nand/raw/txx9ndfmc.c +++ b/drivers/mtd/nand/raw/txx9ndfmc.c @@ -13,7 +13,6 @@ #include #include #include -#include #include #include #include @@ -194,8 +193,8 @@ static int txx9ndfmc_correct_data(struct nand_chip *chip, unsigned char *buf, int stat; for (eccsize = chip->ecc.size; eccsize > 0; eccsize -= 256) { - stat = ecc_sw_hamming_correct(buf, read_ecc, calc_ecc, - chip->ecc.size, false); + stat = rawnand_sw_hamming_correct(chip, buf, read_ecc, + calc_ecc); if (stat < 0) return stat; corrected += stat; -- cgit From 048fbdd599101074285d605936a70a21632da9a4 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:15:03 +0200 Subject: Revert "mtd: rawnand: tmio: Fix external use of SW Hamming ECC helper" This reverts commit 6a4c5ada577467a5f79e06f2c5e69c09983c22fb. Before the introduction of the ECC framework infrastructure, many drivers used the ->calculate/correct() Hamming helpers directly. The point of this framework was to avoid this kind of hackish calls and use a proper and generic API but it is true that in certain cases, drivers still need to use these helpers in order to do ECC computations on behalf of their limited hardware. Right after the introduction of the ECC engine core introduction, it was spotted that it was not possible to use the shiny rawnand software ECC helpers so easily because an ECC engine object should have been allocated and initialized first. While this works well in most cases, for these drivers just leveraging the power of a single helper in conjunction with some pretty old and limited hardware, it did not fit. The idea back then was to declare intermediate helpers which would make use of the exported software ECC engine bare functions while keeping the rawnand layer compatibility. As there was already functions with the rawnand_sw_hamming_ prefix it was decided to declare new local helpers for this purpose in each driver needing one. Besides being far from optimal, this design choice was blamed by Linus when he pulled the "fixes" pull request [1] so that is why now it is time to clean this mess up. The implementation of the rawnand_ecc_sw_* helpers has now been enhanced to support both cases, when the ECC object is instantiated and when it is not. This way, we can still use the existing and exported rawnand helpers while avoiding the need for each driver to declare its own helper, thus this fix from [2] can now be safely reverted. [1] https://lore.kernel.org/lkml/CAHk-=wh_ZHF685Fni8V9is17mj=pFisUaZ_0=gq6nbK+ZcyQmg@mail.gmail.com/ [2] https://lore.kernel.org/linux-mtd/20210413161840.345208-1-miquel.raynal@bootlin.com Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210928221507.199198-5-miquel.raynal@bootlin.com --- drivers/mtd/nand/raw/tmio_nand.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/mtd/nand/raw/tmio_nand.c b/drivers/mtd/nand/raw/tmio_nand.c index 6d93dd31969b..de8e919d0ebe 100644 --- a/drivers/mtd/nand/raw/tmio_nand.c +++ b/drivers/mtd/nand/raw/tmio_nand.c @@ -34,7 +34,6 @@ #include #include #include -#include #include #include #include @@ -293,12 +292,11 @@ static int tmio_nand_correct_data(struct nand_chip *chip, unsigned char *buf, int r0, r1; /* assume ecc.size = 512 and ecc.bytes = 6 */ - r0 = ecc_sw_hamming_correct(buf, read_ecc, calc_ecc, - chip->ecc.size, false); + r0 = rawnand_sw_hamming_correct(chip, buf, read_ecc, calc_ecc); if (r0 < 0) return r0; - r1 = ecc_sw_hamming_correct(buf + 256, read_ecc + 3, calc_ecc + 3, - chip->ecc.size, false); + r1 = rawnand_sw_hamming_correct(chip, buf + 256, read_ecc + 3, + calc_ecc + 3); if (r1 < 0) return r1; return r0 + r1; -- cgit From 1d5f55634c92f3b4f01ed6b390ca2ffe3461250c Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:15:04 +0200 Subject: Revert "mtd: rawnand: sharpsl: Fix external use of SW Hamming ECC helper" This reverts commit 46fcb57e6b7283533ebf8ba17a6bd30fa88bdc9f. Before the introduction of the ECC framework infrastructure, many drivers used the ->calculate/correct() Hamming helpers directly. The point of this framework was to avoid this kind of hackish calls and use a proper and generic API but it is true that in certain cases, drivers still need to use these helpers in order to do ECC computations on behalf of their limited hardware. Right after the introduction of the ECC engine core introduction, it was spotted that it was not possible to use the shiny rawnand software ECC helpers so easily because an ECC engine object should have been allocated and initialized first. While this works well in most cases, for these drivers just leveraging the power of a single helper in conjunction with some pretty old and limited hardware, it did not fit. The idea back then was to declare intermediate helpers which would make use of the exported software ECC engine bare functions while keeping the rawnand layer compatibility. As there was already functions with the rawnand_sw_hamming_ prefix it was decided to declare new local helpers for this purpose in each driver needing one. Besides being far from optimal, this design choice was blamed by Linus when he pulled the "fixes" pull request [1] so that is why now it is time to clean this mess up. The implementation of the rawnand_ecc_sw_* helpers has now been enhanced to support both cases, when the ECC object is instantiated and when it is not. This way, we can still use the existing and exported rawnand helpers while avoiding the need for each driver to declare its own helper, thus this fix from [2] can now be safely reverted. [1] https://lore.kernel.org/lkml/CAHk-=wh_ZHF685Fni8V9is17mj=pFisUaZ_0=gq6nbK+ZcyQmg@mail.gmail.com/ [2] https://lore.kernel.org/linux-mtd/20210413161840.345208-1-miquel.raynal@bootlin.com Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210928221507.199198-6-miquel.raynal@bootlin.com --- drivers/mtd/nand/raw/sharpsl.c | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/drivers/mtd/nand/raw/sharpsl.c b/drivers/mtd/nand/raw/sharpsl.c index 2f1fe464e663..5612ee628425 100644 --- a/drivers/mtd/nand/raw/sharpsl.c +++ b/drivers/mtd/nand/raw/sharpsl.c @@ -11,7 +11,6 @@ #include #include #include -#include #include #include #include @@ -97,15 +96,6 @@ static int sharpsl_nand_calculate_ecc(struct nand_chip *chip, return readb(sharpsl->io + ECCCNTR) != 0; } -static int sharpsl_nand_correct_ecc(struct nand_chip *chip, - unsigned char *buf, - unsigned char *read_ecc, - unsigned char *calc_ecc) -{ - return ecc_sw_hamming_correct(buf, read_ecc, calc_ecc, - chip->ecc.size, false); -} - static int sharpsl_attach_chip(struct nand_chip *chip) { if (chip->ecc.engine_type != NAND_ECC_ENGINE_TYPE_ON_HOST) @@ -116,7 +106,7 @@ static int sharpsl_attach_chip(struct nand_chip *chip) chip->ecc.strength = 1; chip->ecc.hwctl = sharpsl_nand_enable_hwecc; chip->ecc.calculate = sharpsl_nand_calculate_ecc; - chip->ecc.correct = sharpsl_nand_correct_ecc; + chip->ecc.correct = rawnand_sw_hamming_correct; return 0; } -- cgit From 8d1e4218a63e96acd593395d6a8a4cf6095d7457 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:15:05 +0200 Subject: Revert "mtd: rawnand: ndfc: Fix external use of SW Hamming ECC helper" This reverts commit 3e09c0252501829b14b10f14e1982aaab77d0b80. Before the introduction of the ECC framework infrastructure, many drivers used the ->calculate/correct() Hamming helpers directly. The point of this framework was to avoid this kind of hackish calls and use a proper and generic API but it is true that in certain cases, drivers still need to use these helpers in order to do ECC computations on behalf of their limited hardware. Right after the introduction of the ECC engine core introduction, it was spotted that it was not possible to use the shiny rawnand software ECC helpers so easily because an ECC engine object should have been allocated and initialized first. While this works well in most cases, for these drivers just leveraging the power of a single helper in conjunction with some pretty old and limited hardware, it did not fit. The idea back then was to declare intermediate helpers which would make use of the exported software ECC engine bare functions while keeping the rawnand layer compatibility. As there was already functions with the rawnand_sw_hamming_ prefix it was decided to declare new local helpers for this purpose in each driver needing one. Besides being far from optimal, this design choice was blamed by Linus when he pulled the "fixes" pull request [1] so that is why now it is time to clean this mess up. The implementation of the rawnand_ecc_sw_* helpers has now been enhanced to support both cases, when the ECC object is instantiated and when it is not. This way, we can still use the existing and exported rawnand helpers while avoiding the need for each driver to declare its own helper, thus this fix from [2] can now be safely reverted. [1] https://lore.kernel.org/lkml/CAHk-=wh_ZHF685Fni8V9is17mj=pFisUaZ_0=gq6nbK+ZcyQmg@mail.gmail.com/ [2] https://lore.kernel.org/linux-mtd/20210413161840.345208-1-miquel.raynal@bootlin.com Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210928221507.199198-7-miquel.raynal@bootlin.com --- drivers/mtd/nand/raw/ndfc.c | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/drivers/mtd/nand/raw/ndfc.c b/drivers/mtd/nand/raw/ndfc.c index 98d5a94c3a24..338d6b1a189e 100644 --- a/drivers/mtd/nand/raw/ndfc.c +++ b/drivers/mtd/nand/raw/ndfc.c @@ -22,7 +22,6 @@ #include #include #include -#include #include #include #include @@ -101,15 +100,6 @@ static int ndfc_calculate_ecc(struct nand_chip *chip, return 0; } -static int ndfc_correct_ecc(struct nand_chip *chip, - unsigned char *buf, - unsigned char *read_ecc, - unsigned char *calc_ecc) -{ - return ecc_sw_hamming_correct(buf, read_ecc, calc_ecc, - chip->ecc.size, false); -} - /* * Speedups for buffer read/write/verify * @@ -155,7 +145,7 @@ static int ndfc_chip_init(struct ndfc_controller *ndfc, chip->controller = &ndfc->ndfc_control; chip->legacy.read_buf = ndfc_read_buf; chip->legacy.write_buf = ndfc_write_buf; - chip->ecc.correct = ndfc_correct_ecc; + chip->ecc.correct = rawnand_sw_hamming_correct; chip->ecc.hwctl = ndfc_enable_hwecc; chip->ecc.calculate = ndfc_calculate_ecc; chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_ON_HOST; -- cgit From fe972c458fc561113671dde6bd10198cc7719910 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:15:06 +0200 Subject: Revert "mtd: rawnand: lpc32xx_slc: Fix external use of SW Hamming ECC helper" This reverts commit c4b7d7c480d607e4f52d310d9d16b194868d0917. Before the introduction of the ECC framework infrastructure, many drivers used the ->calculate/correct() Hamming helpers directly. The point of this framework was to avoid this kind of hackish calls and use a proper and generic API but it is true that in certain cases, drivers still need to use these helpers in order to do ECC computations on behalf of their limited hardware. Right after the introduction of the ECC engine core introduction, it was spotted that it was not possible to use the shiny rawnand software ECC helpers so easily because an ECC engine object should have been allocated and initialized first. While this works well in most cases, for these drivers just leveraging the power of a single helper in conjunction with some pretty old and limited hardware, it did not fit. The idea back then was to declare intermediate helpers which would make use of the exported software ECC engine bare functions while keeping the rawnand layer compatibility. As there was already functions with the rawnand_sw_hamming_ prefix it was decided to declare new local helpers for this purpose in each driver needing one. Besides being far from optimal, this design choice was blamed by Linus when he pulled the "fixes" pull request [1] so that is why now it is time to clean this mess up. The implementation of the rawnand_ecc_sw_* helpers has now been enhanced to support both cases, when the ECC object is instantiated and when it is not. This way, we can still use the existing and exported rawnand helpers while avoiding the need for each driver to declare its own helper, thus this fix from [2] can now be safely reverted. [1] https://lore.kernel.org/lkml/CAHk-=wh_ZHF685Fni8V9is17mj=pFisUaZ_0=gq6nbK+ZcyQmg@mail.gmail.com/ [2] https://lore.kernel.org/linux-mtd/20210413161840.345208-1-miquel.raynal@bootlin.com Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210928221507.199198-8-miquel.raynal@bootlin.com --- drivers/mtd/nand/raw/lpc32xx_slc.c | 15 +-------------- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/drivers/mtd/nand/raw/lpc32xx_slc.c b/drivers/mtd/nand/raw/lpc32xx_slc.c index d7dfc6fd85ca..6b7269cfb7d8 100644 --- a/drivers/mtd/nand/raw/lpc32xx_slc.c +++ b/drivers/mtd/nand/raw/lpc32xx_slc.c @@ -27,7 +27,6 @@ #include #include #include -#include #define LPC32XX_MODNAME "lpc32xx-nand" @@ -345,18 +344,6 @@ static int lpc32xx_nand_ecc_calculate(struct nand_chip *chip, return 0; } -/* - * Corrects the data - */ -static int lpc32xx_nand_ecc_correct(struct nand_chip *chip, - unsigned char *buf, - unsigned char *read_ecc, - unsigned char *calc_ecc) -{ - return ecc_sw_hamming_correct(buf, read_ecc, calc_ecc, - chip->ecc.size, false); -} - /* * Read a single byte from NAND device */ @@ -815,7 +802,7 @@ static int lpc32xx_nand_attach_chip(struct nand_chip *chip) chip->ecc.write_oob = lpc32xx_nand_write_oob_syndrome; chip->ecc.read_oob = lpc32xx_nand_read_oob_syndrome; chip->ecc.calculate = lpc32xx_nand_ecc_calculate; - chip->ecc.correct = lpc32xx_nand_ecc_correct; + chip->ecc.correct = rawnand_sw_hamming_correct; chip->ecc.hwctl = lpc32xx_nand_ecc_enable; /* -- cgit From c625823ad8c095afb9601e06ea9fba07c865f378 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:15:07 +0200 Subject: Revert "mtd: rawnand: cs553x: Fix external use of SW Hamming ECC helper" This reverts commit 56a8d3fd1f342d10ee7b27e9ac0f4d00b5fbb91c. Before the introduction of the ECC framework infrastructure, many drivers used the ->calculate/correct() Hamming helpers directly. The point of this framework was to avoid this kind of hackish calls and use a proper and generic API but it is true that in certain cases, drivers still need to use these helpers in order to do ECC computations on behalf of their limited hardware. Right after the introduction of the ECC engine core introduction, it was spotted that it was not possible to use the shiny rawnand software ECC helpers so easily because an ECC engine object should have been allocated and initialized first. While this works well in most cases, for these drivers just leveraging the power of a single helper in conjunction with some pretty old and limited hardware, it did not fit. The idea back then was to declare intermediate helpers which would make use of the exported software ECC engine bare functions while keeping the rawnand layer compatibility. As there was already functions with the rawnand_sw_hamming_ prefix it was decided to declare new local helpers for this purpose in each driver needing one. Besides being far from optimal, this design choice was blamed by Linus when he pulled the "fixes" pull request [1] so that is why now it is time to clean this mess up. The implementation of the rawnand_ecc_sw_* helpers has now been enhanced to support both cases, when the ECC object is instantiated and when it is not. This way, we can still use the existing and exported rawnand helpers while avoiding the need for each driver to declare its own helper, thus this fix from [2] can now be safely reverted. [1] https://lore.kernel.org/lkml/CAHk-=wh_ZHF685Fni8V9is17mj=pFisUaZ_0=gq6nbK+ZcyQmg@mail.gmail.com/ [2] https://lore.kernel.org/linux-mtd/20210413161840.345208-1-miquel.raynal@bootlin.com Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210928221507.199198-9-miquel.raynal@bootlin.com --- drivers/mtd/nand/raw/cs553x_nand.c | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/drivers/mtd/nand/raw/cs553x_nand.c b/drivers/mtd/nand/raw/cs553x_nand.c index df40927e5678..6edf78c16fc8 100644 --- a/drivers/mtd/nand/raw/cs553x_nand.c +++ b/drivers/mtd/nand/raw/cs553x_nand.c @@ -18,7 +18,6 @@ #include #include #include -#include #include #include #include @@ -241,15 +240,6 @@ static int cs_calculate_ecc(struct nand_chip *this, const u_char *dat, return 0; } -static int cs553x_ecc_correct(struct nand_chip *chip, - unsigned char *buf, - unsigned char *read_ecc, - unsigned char *calc_ecc) -{ - return ecc_sw_hamming_correct(buf, read_ecc, calc_ecc, - chip->ecc.size, false); -} - static struct cs553x_nand_controller *controllers[4]; static int cs553x_attach_chip(struct nand_chip *chip) @@ -261,7 +251,7 @@ static int cs553x_attach_chip(struct nand_chip *chip) chip->ecc.bytes = 3; chip->ecc.hwctl = cs_enable_hwecc; chip->ecc.calculate = cs_calculate_ecc; - chip->ecc.correct = cs553x_ecc_correct; + chip->ecc.correct = rawnand_sw_hamming_correct; chip->ecc.strength = 1; return 0; -- cgit From d707bb74daae07879e0fc1b4b960f8f2d0a5fe5d Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:22:40 +0200 Subject: mtd: rawnand: ams-delta: Keep the driver compatible with on-die ECC engines Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: 59d93473323a ("mtd: rawnand: ams-delta: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-2-miquel.raynal@bootlin.com --- drivers/mtd/nand/raw/ams-delta.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/ams-delta.c b/drivers/mtd/nand/raw/ams-delta.c index ff1697f899ba..13de39aa3288 100644 --- a/drivers/mtd/nand/raw/ams-delta.c +++ b/drivers/mtd/nand/raw/ams-delta.c @@ -217,9 +217,8 @@ static int gpio_nand_setup_interface(struct nand_chip *this, int csline, static int gpio_nand_attach_chip(struct nand_chip *chip) { - chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; - - if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) + if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_SOFT && + chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) chip->ecc.algo = NAND_ECC_ALGO_HAMMING; return 0; @@ -370,6 +369,13 @@ static int gpio_nand_probe(struct platform_device *pdev) /* Release write protection */ gpiod_set_value(priv->gpiod_nwp, 0); + /* + * This driver assumes that the default ECC engine should be TYPE_SOFT. + * Set ->engine_type before registering the NAND devices in order to + * provide a driver specific default value. + */ + this->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; + /* Scan to find existence of the device */ err = nand_scan(this, 1); if (err) -- cgit From 7e3cdba176ba59eaf4d463d273da0718e3626140 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:22:41 +0200 Subject: mtd: rawnand: au1550nd: Keep the driver compatible with on-die ECC engines Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: dbffc8ccdf3a ("mtd: rawnand: au1550: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-3-miquel.raynal@bootlin.com --- drivers/mtd/nand/raw/au1550nd.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/au1550nd.c b/drivers/mtd/nand/raw/au1550nd.c index 99116896cfd6..5aa3a06d740c 100644 --- a/drivers/mtd/nand/raw/au1550nd.c +++ b/drivers/mtd/nand/raw/au1550nd.c @@ -239,9 +239,8 @@ static int au1550nd_exec_op(struct nand_chip *this, static int au1550nd_attach_chip(struct nand_chip *chip) { - chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; - - if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) + if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_SOFT && + chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) chip->ecc.algo = NAND_ECC_ALGO_HAMMING; return 0; @@ -310,6 +309,13 @@ static int au1550nd_probe(struct platform_device *pdev) if (pd->devwidth) this->options |= NAND_BUSWIDTH_16; + /* + * This driver assumes that the default ECC engine should be TYPE_SOFT. + * Set ->engine_type before registering the NAND devices in order to + * provide a driver specific default value. + */ + this->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; + ret = nand_scan(this, 1); if (ret) { dev_err(&pdev->dev, "NAND scan failed with %d\n", ret); -- cgit From b5b5b4dc6fcd8194b9dd38c8acdc5ab71adf44f8 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:22:42 +0200 Subject: mtd: rawnand: gpio: Keep the driver compatible with on-die ECC engines Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: f6341f6448e0 ("mtd: rawnand: gpio: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-4-miquel.raynal@bootlin.com --- drivers/mtd/nand/raw/gpio.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/gpio.c b/drivers/mtd/nand/raw/gpio.c index 8901c4aa0c21..dcf28cff760d 100644 --- a/drivers/mtd/nand/raw/gpio.c +++ b/drivers/mtd/nand/raw/gpio.c @@ -163,9 +163,8 @@ static int gpio_nand_exec_op(struct nand_chip *chip, static int gpio_nand_attach_chip(struct nand_chip *chip) { - chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; - - if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) + if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_SOFT && + chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) chip->ecc.algo = NAND_ECC_ALGO_HAMMING; return 0; @@ -364,6 +363,13 @@ static int gpio_nand_probe(struct platform_device *pdev) if (gpiomtd->nwp && !IS_ERR(gpiomtd->nwp)) gpiod_direction_output(gpiomtd->nwp, 1); + /* + * This driver assumes that the default ECC engine should be TYPE_SOFT. + * Set ->engine_type before registering the NAND devices in order to + * provide a driver specific default value. + */ + chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; + ret = nand_scan(chip, 1); if (ret) goto err_wp; -- cgit From f9d8570b7fd6f4f08528ce2f5e39787a8a260cd6 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:22:43 +0200 Subject: mtd: rawnand: mpc5121: Keep the driver compatible with on-die ECC engines Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: 6dd09f775b72 ("mtd: rawnand: mpc5121: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-5-miquel.raynal@bootlin.com --- drivers/mtd/nand/raw/mpc5121_nfc.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/mpc5121_nfc.c b/drivers/mtd/nand/raw/mpc5121_nfc.c index bcd4a556c959..cb293c50acb8 100644 --- a/drivers/mtd/nand/raw/mpc5121_nfc.c +++ b/drivers/mtd/nand/raw/mpc5121_nfc.c @@ -605,9 +605,8 @@ static void mpc5121_nfc_free(struct device *dev, struct mtd_info *mtd) static int mpc5121_nfc_attach_chip(struct nand_chip *chip) { - chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; - - if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) + if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_SOFT && + chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) chip->ecc.algo = NAND_ECC_ALGO_HAMMING; return 0; @@ -772,6 +771,13 @@ static int mpc5121_nfc_probe(struct platform_device *op) goto error; } + /* + * This driver assumes that the default ECC engine should be TYPE_SOFT. + * Set ->engine_type before registering the NAND devices in order to + * provide a driver specific default value. + */ + chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; + /* Detect NAND chips */ retval = nand_scan(chip, be32_to_cpup(chips_no)); if (retval) { -- cgit From 194ac63de6ff56d30c48e3ac19c8a412f9c1408e Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:22:44 +0200 Subject: mtd: rawnand: orion: Keep the driver compatible with on-die ECC engines Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: 553508cec2e8 ("mtd: rawnand: orion: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-6-miquel.raynal@bootlin.com --- drivers/mtd/nand/raw/orion_nand.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/orion_nand.c b/drivers/mtd/nand/raw/orion_nand.c index 66211c9311d2..2c87c7d89205 100644 --- a/drivers/mtd/nand/raw/orion_nand.c +++ b/drivers/mtd/nand/raw/orion_nand.c @@ -85,9 +85,8 @@ static void orion_nand_read_buf(struct nand_chip *chip, uint8_t *buf, int len) static int orion_nand_attach_chip(struct nand_chip *chip) { - chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; - - if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) + if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_SOFT && + chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) chip->ecc.algo = NAND_ECC_ALGO_HAMMING; return 0; @@ -190,6 +189,13 @@ static int __init orion_nand_probe(struct platform_device *pdev) return ret; } + /* + * This driver assumes that the default ECC engine should be TYPE_SOFT. + * Set ->engine_type before registering the NAND devices in order to + * provide a driver specific default value. + */ + nc->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; + ret = nand_scan(nc, 1); if (ret) goto no_dev; -- cgit From f16b7d2a5e810fcf4b15d096246d0d445da9cc88 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:22:45 +0200 Subject: mtd: rawnand: pasemi: Keep the driver compatible with on-die ECC engines Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: 8fc6f1f042b2 ("mtd: rawnand: pasemi: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-7-miquel.raynal@bootlin.com --- drivers/mtd/nand/raw/pasemi_nand.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/pasemi_nand.c b/drivers/mtd/nand/raw/pasemi_nand.c index 789f33312c15..c176036453ed 100644 --- a/drivers/mtd/nand/raw/pasemi_nand.c +++ b/drivers/mtd/nand/raw/pasemi_nand.c @@ -75,9 +75,8 @@ static int pasemi_device_ready(struct nand_chip *chip) static int pasemi_attach_chip(struct nand_chip *chip) { - chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; - - if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) + if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_SOFT && + chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) chip->ecc.algo = NAND_ECC_ALGO_HAMMING; return 0; @@ -154,6 +153,13 @@ static int pasemi_nand_probe(struct platform_device *ofdev) /* Enable the following for a flash based bad block table */ chip->bbt_options = NAND_BBT_USE_FLASH; + /* + * This driver assumes that the default ECC engine should be TYPE_SOFT. + * Set ->engine_type before registering the NAND devices in order to + * provide a driver specific default value. + */ + chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; + /* Scan to find existence of the device */ err = nand_scan(chip, 1); if (err) -- cgit From 325fd539fc84f0aaa0ceb9d7d3b8718582473dc5 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:22:46 +0200 Subject: mtd: rawnand: plat_nand: Keep the driver compatible with on-die ECC engines Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: 612e048e6aab ("mtd: rawnand: plat_nand: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-8-miquel.raynal@bootlin.com --- drivers/mtd/nand/raw/plat_nand.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/plat_nand.c b/drivers/mtd/nand/raw/plat_nand.c index c1b2072cb507..7e0d0a8dfd1e 100644 --- a/drivers/mtd/nand/raw/plat_nand.c +++ b/drivers/mtd/nand/raw/plat_nand.c @@ -21,9 +21,8 @@ struct plat_nand_data { static int plat_nand_attach_chip(struct nand_chip *chip) { - chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; - - if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) + if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_SOFT && + chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) chip->ecc.algo = NAND_ECC_ALGO_HAMMING; return 0; @@ -92,6 +91,13 @@ static int plat_nand_probe(struct platform_device *pdev) goto out; } + /* + * This driver assumes that the default ECC engine should be TYPE_SOFT. + * Set ->engine_type before registering the NAND devices in order to + * provide a driver specific default value. + */ + data->chip.ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; + /* Scan to find existence of the device */ err = nand_scan(&data->chip, pdata->chip.nr_chips); if (err) -- cgit From b4ebddd6540d78a7f977b3fea0261bd575c6ffe2 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:22:47 +0200 Subject: mtd: rawnand: socrates: Keep the driver compatible with on-die ECC engines Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: b36bf0a0fe5d ("mtd: rawnand: socrates: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-9-miquel.raynal@bootlin.com --- drivers/mtd/nand/raw/socrates_nand.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/socrates_nand.c b/drivers/mtd/nand/raw/socrates_nand.c index 70f8305c9b6e..fb39cc7ebce0 100644 --- a/drivers/mtd/nand/raw/socrates_nand.c +++ b/drivers/mtd/nand/raw/socrates_nand.c @@ -119,9 +119,8 @@ static int socrates_nand_device_ready(struct nand_chip *nand_chip) static int socrates_attach_chip(struct nand_chip *chip) { - chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; - - if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) + if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_SOFT && + chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) chip->ecc.algo = NAND_ECC_ALGO_HAMMING; return 0; @@ -175,6 +174,13 @@ static int socrates_nand_probe(struct platform_device *ofdev) /* TODO: I have no idea what real delay is. */ nand_chip->legacy.chip_delay = 20; /* 20us command delay time */ + /* + * This driver assumes that the default ECC engine should be TYPE_SOFT. + * Set ->engine_type before registering the NAND devices in order to + * provide a driver specific default value. + */ + nand_chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; + dev_set_drvdata(&ofdev->dev, host); res = nand_scan(nand_chip, 1); -- cgit From 6bcd2960af1b7bacb2f1e710ab0c0b802d900501 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:22:48 +0200 Subject: mtd: rawnand: xway: Keep the driver compatible with on-die ECC engines Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: d525914b5bd8 ("mtd: rawnand: xway: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Cc: Jan Hoffmann Cc: Kestrel seventyfour Signed-off-by: Miquel Raynal Tested-by: Jan Hoffmann Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-10-miquel.raynal@bootlin.com --- drivers/mtd/nand/raw/xway_nand.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/xway_nand.c b/drivers/mtd/nand/raw/xway_nand.c index 92067bd55384..035b82aa2f4a 100644 --- a/drivers/mtd/nand/raw/xway_nand.c +++ b/drivers/mtd/nand/raw/xway_nand.c @@ -148,9 +148,8 @@ static void xway_write_buf(struct nand_chip *chip, const u_char *buf, int len) static int xway_attach_chip(struct nand_chip *chip) { - chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; - - if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) + if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_SOFT && + chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) chip->ecc.algo = NAND_ECC_ALGO_HAMMING; return 0; @@ -217,6 +216,13 @@ static int xway_nand_probe(struct platform_device *pdev) | NAND_CON_SE_P | NAND_CON_WP_P | NAND_CON_PRE_P | cs_flag, EBU_NAND_CON); + /* + * This driver assumes that the default ECC engine should be TYPE_SOFT. + * Set ->engine_type before registering the NAND devices in order to + * provide a driver specific default value. + */ + data->chip.ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; + /* Scan to find existence of the device */ err = nand_scan(&data->chip, 1); if (err) -- cgit From eec417fd317a95a79257c20b3a1d66d4027549df Mon Sep 17 00:00:00 2001 From: Chris Morgan Date: Thu, 30 Sep 2021 11:24:02 -0500 Subject: mtd: rawnand: hynix: Add support for H27UCG8T2ETR-BC MLC NAND Add support for the H27UCG8T2ETR-BC MLC NAND. The NAND is used widely in the NTC CHIP, is an MLC type NAND, and is 8GB in size. Neither JEDEC nor ONFI detection identifies it correctly, so the ID is added to the nand_ids.c file. Additionally, per the datasheet this NAND appears to use the same paired pages scheme as the Toshiba TC58TEG5DCLTA00 (dist3), so add support for that to enable use in SLC emulation mode. Tested on a NTC CHIP the device is able to write to a ubifs formatted partition, and then have U-Boot (with proposed patches) boot from a kernel located on that ubifs formatted partition. Signed-off-by: Chris Morgan Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210930162402.344-1-macroalpha82@gmail.com --- drivers/mtd/nand/raw/nand_hynix.c | 14 ++++++++++++++ drivers/mtd/nand/raw/nand_ids.c | 4 ++++ 2 files changed, 18 insertions(+) diff --git a/drivers/mtd/nand/raw/nand_hynix.c b/drivers/mtd/nand/raw/nand_hynix.c index a9f50c9af109..0d4d4bbfdece 100644 --- a/drivers/mtd/nand/raw/nand_hynix.c +++ b/drivers/mtd/nand/raw/nand_hynix.c @@ -686,6 +686,16 @@ h27ucg8t2atrbc_choose_interface_config(struct nand_chip *chip, return nand_choose_best_sdr_timings(chip, iface, NULL); } +static int h27ucg8t2etrbc_init(struct nand_chip *chip) +{ + struct mtd_info *mtd = nand_to_mtd(chip); + + chip->options |= NAND_NEED_SCRAMBLING; + mtd_set_pairing_scheme(mtd, &dist3_pairing_scheme); + + return 0; +} + static int hynix_nand_init(struct nand_chip *chip) { struct hynix_nand *hynix; @@ -707,6 +717,10 @@ static int hynix_nand_init(struct nand_chip *chip) chip->ops.choose_interface_config = h27ucg8t2atrbc_choose_interface_config; + if (!strncmp("H27UCG8T2ETR-BC", chip->parameters.model, + sizeof("H27UCG8T2ETR-BC") - 1)) + h27ucg8t2etrbc_init(chip); + ret = hynix_nand_rr_init(chip); if (ret) hynix_nand_cleanup(chip); diff --git a/drivers/mtd/nand/raw/nand_ids.c b/drivers/mtd/nand/raw/nand_ids.c index b9945791a9d7..6e41902be35f 100644 --- a/drivers/mtd/nand/raw/nand_ids.c +++ b/drivers/mtd/nand/raw/nand_ids.c @@ -51,6 +51,10 @@ struct nand_flash_dev nand_flash_ids[] = { { .id = {0xad, 0xde, 0x94, 0xda, 0x74, 0xc4} }, SZ_8K, SZ_8K, SZ_2M, NAND_NEED_SCRAMBLING, 6, 640, NAND_ECC_INFO(40, SZ_1K) }, + {"H27UCG8T2ETR-BC 64G 3.3V 8-bit", + { .id = {0xad, 0xde, 0x14, 0xa7, 0x42, 0x4a} }, + SZ_16K, SZ_8K, SZ_4M, NAND_NEED_SCRAMBLING, 6, 1664, + NAND_ECC_INFO(40, SZ_1K) }, {"TH58NVG2S3HBAI4 4G 3.3V 8-bit", { .id = {0x98, 0xdc, 0x91, 0x15, 0x76} }, SZ_2K, SZ_512, SZ_128K, 0, 5, 128, NAND_ECC_INFO(8, SZ_512) }, -- cgit From 73e197df1949347bbc1902605b6c7fe8e3b04249 Mon Sep 17 00:00:00 2001 From: Manivannan Sadhasivam Date: Mon, 4 Oct 2021 18:09:26 +0530 Subject: MAINTAINERS: Add entry for Qualcomm NAND controller driver Since I maintain the dt-binding for this controller, I'm stepping forward to maintain the driver also. Signed-off-by: Manivannan Sadhasivam Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20211004123926.53462-1-manivannan.sadhasivam@linaro.org --- MAINTAINERS | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index eeb4c70b3d5b..f4c590b22636 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -15572,6 +15572,14 @@ S: Maintained F: Documentation/devicetree/bindings/regulator/vqmmc-ipq4019-regulator.yaml F: drivers/regulator/vqmmc-ipq4019-regulator.c +QUALCOMM NAND CONTROLLER DRIVER +M: Manivannan Sadhasivam +L: linux-mtd@lists.infradead.org +L: linux-arm-msm@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/mtd/qcom,nandc.yaml +F: drivers/mtd/nand/raw/qcom_nandc.c + QUALCOMM RMNET DRIVER M: Subash Abhinov Kasiviswanathan M: Sean Tranchetti -- cgit From fc9e18f9e987ad46722dad53adab1c12148c213c Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Fri, 8 Oct 2021 18:36:40 +0200 Subject: mtd: rawnand: arasan: Prevent an unsupported configuration Under the following conditions: * after rounding up by 4 the number of bytes to transfer (this is related to the controller's internal constraints), * if this (rounded) amount of data is situated beyond the end of the device, * and only in NV-DDR mode, the Arasan NAND controller timeouts. This currently can happen in a particular helper used when picking software ECC algorithms. Let's prevent this situation by refusing to use the NV-DDR interface with software engines. Fixes: 4edde6031458 ("mtd: rawnand: arasan: Support NV-DDR interface") Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20211008163640.1753821-1-miquel.raynal@bootlin.com --- drivers/mtd/nand/raw/arasan-nand-controller.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/drivers/mtd/nand/raw/arasan-nand-controller.c b/drivers/mtd/nand/raw/arasan-nand-controller.c index 9cbcc698c64d..53bd10738418 100644 --- a/drivers/mtd/nand/raw/arasan-nand-controller.c +++ b/drivers/mtd/nand/raw/arasan-nand-controller.c @@ -973,6 +973,21 @@ static int anfc_setup_interface(struct nand_chip *chip, int target, nvddr = nand_get_nvddr_timings(conf); if (IS_ERR(nvddr)) return PTR_ERR(nvddr); + + /* + * The controller only supports data payload requests which are + * a multiple of 4. In practice, most data accesses are 4-byte + * aligned and this is not an issue. However, rounding up will + * simply be refused by the controller if we reached the end of + * the device *and* we are using the NV-DDR interface(!). In + * this situation, unaligned data requests ending at the device + * boundary will confuse the controller and cannot be performed. + * + * This is something that happens in nand_read_subpage() when + * selecting software ECC support and must be avoided. + */ + if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_SOFT) + return -ENOTSUPP; } else { sdr = nand_get_sdr_timings(conf); if (IS_ERR(sdr)) -- cgit From 603362b4a58393061dcfed1c7f0d0fd4aba61126 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Mon, 27 Sep 2021 16:10:37 +0200 Subject: mtd: fixup CFI on ixp4xx drivers/mtd/maps/ixp4xx.c requires MTD_CFI_BE_BYTE_SWAP to be set in order to compile. drivers/mtd/maps/ixp4xx.c:57:4: error: #error CONFIG_MTD_CFI_BE_BYTE_SWAP required This patch avoids the #error output by enforcing the policy in Kconfig. Not sure if this is the right approach, but it helps doing randconfig builds. Signed-off-by: Arnd Bergmann Acked-by: Linus Walleij Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210927141045.1597593-1-arnd@kernel.org --- drivers/mtd/chips/Kconfig | 2 ++ drivers/mtd/maps/Kconfig | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/chips/Kconfig b/drivers/mtd/chips/Kconfig index aef14990e5f7..19726ebd973d 100644 --- a/drivers/mtd/chips/Kconfig +++ b/drivers/mtd/chips/Kconfig @@ -55,12 +55,14 @@ choice LITTLE_ENDIAN_BYTE, if the bytes are reversed. config MTD_CFI_NOSWAP + depends on !ARCH_IXP4XX || CPU_BIG_ENDIAN bool "NO" config MTD_CFI_BE_BYTE_SWAP bool "BIG_ENDIAN_BYTE" config MTD_CFI_LE_BYTE_SWAP + depends on !ARCH_IXP4XX bool "LITTLE_ENDIAN_BYTE" endchoice diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig index aaa164b977fe..4945caa88345 100644 --- a/drivers/mtd/maps/Kconfig +++ b/drivers/mtd/maps/Kconfig @@ -302,7 +302,7 @@ config MTD_DC21285 config MTD_IXP4XX tristate "CFI Flash device mapped on Intel IXP4xx based systems" - depends on MTD_CFI && MTD_COMPLEX_MAPPINGS && ARCH_IXP4XX + depends on MTD_CFI && MTD_COMPLEX_MAPPINGS && ARCH_IXP4XX && MTD_CFI_ADV_OPTIONS help This enables MTD access to flash devices on platforms based on Intel's IXP4xx family of network processors such as the -- cgit From a04e96537cc64b63fbeb300df2503167bb54f2a1 Mon Sep 17 00:00:00 2001 From: Joachim Wiberg Date: Sat, 9 Oct 2021 08:09:54 +0200 Subject: mtd: block2mtd: minor refactor to avoid hard coded constant Signed-off-by: Joachim Wiberg Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20211009060955.552636-2-troglobit@gmail.com --- drivers/mtd/devices/block2mtd.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/devices/block2mtd.c b/drivers/mtd/devices/block2mtd.c index c08721b11642..6c2871788d59 100644 --- a/drivers/mtd/devices/block2mtd.c +++ b/drivers/mtd/devices/block2mtd.c @@ -31,6 +31,9 @@ #include #include +/* Maximum number of comma-separated items in the 'block2mtd=' parameter */ +#define BLOCK2MTD_PARAM_MAX_COUNT 2 + /* Info for the block device */ struct block2mtd_dev { struct list_head list; @@ -381,7 +384,7 @@ static int block2mtd_setup2(const char *val) /* 80 for device, 12 for erase size, 80 for name, 8 for timeout */ char buf[80 + 12 + 80 + 8]; char *str = buf; - char *token[2]; + char *token[BLOCK2MTD_PARAM_MAX_COUNT]; char *name; size_t erase_size = PAGE_SIZE; unsigned long timeout = MTD_DEFAULT_TIMEOUT; @@ -395,7 +398,7 @@ static int block2mtd_setup2(const char *val) strcpy(str, val); kill_final_newline(str); - for (i = 0; i < 2; i++) + for (i = 0; i < BLOCK2MTD_PARAM_MAX_COUNT; i++) token[i] = strsep(&str, ","); if (str) { -- cgit From 7b09acdcb944a9be6acc38ab1aa8a0ffd08871c1 Mon Sep 17 00:00:00 2001 From: Joachim Wiberg Date: Sat, 9 Oct 2021 08:09:55 +0200 Subject: mtd: block2mtd: add support for an optional custom MTD label This patch adds support for an optional MTD label for mtd2block emulated MTD devices. Useful when, e.g., testing device images using Qemu. The following line in /etc/fstab can then be used to mount a file system regardless if running on an embedded system, or emulated with block2mtd: mtd:Config /mnt jffs2 noatime,nodiratime 0 0 Kernel command line syntax in the emulated case: block2mtd.block2mtd=/dev/sda,,Config Notice the ',,' it is the optional erase_size, which like before this patch, defaults to PAGE_SIZE when omitted. Hence the strlen() check. Signed-off-by: Joachim Wiberg Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20211009060955.552636-3-troglobit@gmail.com --- drivers/mtd/devices/block2mtd.c | 24 +++++++++++++++++------- 1 file changed, 17 insertions(+), 7 deletions(-) diff --git a/drivers/mtd/devices/block2mtd.c b/drivers/mtd/devices/block2mtd.c index 6c2871788d59..40d7211485da 100644 --- a/drivers/mtd/devices/block2mtd.c +++ b/drivers/mtd/devices/block2mtd.c @@ -32,7 +32,7 @@ #include /* Maximum number of comma-separated items in the 'block2mtd=' parameter */ -#define BLOCK2MTD_PARAM_MAX_COUNT 2 +#define BLOCK2MTD_PARAM_MAX_COUNT 3 /* Info for the block device */ struct block2mtd_dev { @@ -217,7 +217,7 @@ static void block2mtd_free_device(struct block2mtd_dev *dev) static struct block2mtd_dev *add_device(char *devname, int erase_size, - int timeout) + char *label, int timeout) { #ifndef MODULE int i; @@ -281,7 +281,10 @@ static struct block2mtd_dev *add_device(char *devname, int erase_size, /* Setup the MTD structure */ /* make the name contain the block device in */ - name = kasprintf(GFP_KERNEL, "block2mtd: %s", devname); + if (!label) + name = kasprintf(GFP_KERNEL, "block2mtd: %s", devname); + else + name = kstrdup(label, GFP_KERNEL); if (!name) goto err_destroy_mutex; @@ -308,7 +311,7 @@ static struct block2mtd_dev *add_device(char *devname, int erase_size, list_add(&dev->list, &blkmtd_device_list); pr_info("mtd%d: [%s] erase_size = %dKiB [%d]\n", dev->mtd.index, - dev->mtd.name + strlen("block2mtd: "), + label ? label : dev->mtd.name + strlen("block2mtd: "), dev->mtd.erasesize >> 10, dev->mtd.erasesize); return dev; @@ -386,6 +389,7 @@ static int block2mtd_setup2(const char *val) char *str = buf; char *token[BLOCK2MTD_PARAM_MAX_COUNT]; char *name; + char *label = NULL; size_t erase_size = PAGE_SIZE; unsigned long timeout = MTD_DEFAULT_TIMEOUT; int i, ret; @@ -417,7 +421,8 @@ static int block2mtd_setup2(const char *val) return 0; } - if (token[1]) { + /* Optional argument when custom label is used */ + if (token[1] && strlen(token[1])) { ret = parse_num(&erase_size, token[1]); if (ret) { pr_err("illegal erase size\n"); @@ -425,7 +430,12 @@ static int block2mtd_setup2(const char *val) } } - add_device(name, erase_size, timeout); + if (token[2]) { + label = token[2]; + pr_info("Using custom MTD label '%s' for dev %s\n", label, name); + } + + add_device(name, erase_size, label, timeout); return 0; } @@ -459,7 +469,7 @@ static int block2mtd_setup(const char *val, const struct kernel_param *kp) module_param_call(block2mtd, block2mtd_setup, NULL, NULL, 0200); -MODULE_PARM_DESC(block2mtd, "Device to use. \"block2mtd=[,]\""); +MODULE_PARM_DESC(block2mtd, "Device to use. \"block2mtd=[,[][,