From a2aec2c86ef0cad0fd6be718cfeb5cf5eefbfca9 Mon Sep 17 00:00:00 2001 From: "GONG, Ruiqi" Date: Mon, 30 Aug 2021 16:33:56 +0800 Subject: [PATCH 01/39] 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 From c606d4f77c8a637c0563a206b080c5663f72b61a Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:40:30 +0800 Subject: [PATCH 02/39] 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); From df9e5170bc4d2d96a0c5dcfd3960c3e248a37218 Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:40:38 +0800 Subject: [PATCH 03/39] 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); From 5f14a8ca1b493a3c633ff549fb7d494887d7804a Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:41:15 +0800 Subject: [PATCH 04/39] 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); From 557de1cfabd6ea5476e5364a00d23d26bdfa3d4d Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:41:22 +0800 Subject: [PATCH 05/39] 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); From fe6b7a9f9159a3a55f5227e03c97f65b4d81dc71 Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:41:30 +0800 Subject: [PATCH 06/39] 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); From 1cda2633999a9431bc00d7881e2ea96cff5da22f Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:41:37 +0800 Subject: [PATCH 07/39] 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); From 5da7bb27a582b8f232c09dd1067eb7a254c4d4ee Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:41:44 +0800 Subject: [PATCH 08/39] 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; From 8826e1107236d8668cfbcf8b31caea3ac943de1e Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:41:52 +0800 Subject: [PATCH 09/39] 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); From 7b7be21861819afcc0b82cd6f0fe5baef40374cd Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:41:59 +0800 Subject: [PATCH 10/39] 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); From f47dca43c51f6d1fa0cc1574badc748724d9286c Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:42:07 +0800 Subject: [PATCH 11/39] 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); From 7e2561430dff0a1bb9ab794e70fcaa56852e10f9 Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:42:14 +0800 Subject: [PATCH 12/39] 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); From 8d77c55f090def05f450df8aa6ee16ec6f4d01ba Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:42:22 +0800 Subject: [PATCH 13/39] 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]); } From 2f597bc45e47e245e30265de8494423c3a1a7900 Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:42:29 +0800 Subject: [PATCH 14/39] 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); From 524bd02a6ff8c25a88077747020c1d0a7a94594b Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:42:37 +0800 Subject: [PATCH 15/39] 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); From 2d77b08eaf0b2f269512c200c441bb1cda59d978 Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:42:44 +0800 Subject: [PATCH 16/39] 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); From abac656349cb9f081bc3b0a4c75d98486ade77f0 Mon Sep 17 00:00:00 2001 From: Cai Huoqing Date: Wed, 1 Sep 2021 15:42:51 +0800 Subject: [PATCH 17/39] 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); From 46a0dc10fb32bec3e765e51bf71fbc070dc77ca3 Mon Sep 17 00:00:00 2001 From: Evgeny Novikov Date: Fri, 3 Sep 2021 11:26:53 +0300 Subject: [PATCH 18/39] 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); From c2606ddcf5ad1969ceffe3c98d427b272243e150 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Fri, 24 Sep 2021 15:32:23 +0200 Subject: [PATCH 19/39] 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" From 9be1446ece291a1f08164bd056bed3d698681f8b Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:15:00 +0200 Subject: [PATCH 20/39] 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 */ From d8467112d645ec56760c78928e1e5a3f6faa9b74 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:15:01 +0200 Subject: [PATCH 21/39] 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); From e7f466c51ce9179a7b5105f93fdb3e85ef6b61ce Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:15:02 +0200 Subject: [PATCH 22/39] 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; From 048fbdd599101074285d605936a70a21632da9a4 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:15:03 +0200 Subject: [PATCH 23/39] 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; From 1d5f55634c92f3b4f01ed6b390ca2ffe3461250c Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:15:04 +0200 Subject: [PATCH 24/39] 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; } From 8d1e4218a63e96acd593395d6a8a4cf6095d7457 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:15:05 +0200 Subject: [PATCH 25/39] 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; From fe972c458fc561113671dde6bd10198cc7719910 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:15:06 +0200 Subject: [PATCH 26/39] 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; /* From c625823ad8c095afb9601e06ea9fba07c865f378 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:15:07 +0200 Subject: [PATCH 27/39] 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; From d707bb74daae07879e0fc1b4b960f8f2d0a5fe5d Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:22:40 +0200 Subject: [PATCH 28/39] 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) From 7e3cdba176ba59eaf4d463d273da0718e3626140 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:22:41 +0200 Subject: [PATCH 29/39] 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); From b5b5b4dc6fcd8194b9dd38c8acdc5ab71adf44f8 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:22:42 +0200 Subject: [PATCH 30/39] 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; From f9d8570b7fd6f4f08528ce2f5e39787a8a260cd6 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:22:43 +0200 Subject: [PATCH 31/39] 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) { From 194ac63de6ff56d30c48e3ac19c8a412f9c1408e Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:22:44 +0200 Subject: [PATCH 32/39] 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; From f16b7d2a5e810fcf4b15d096246d0d445da9cc88 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:22:45 +0200 Subject: [PATCH 33/39] 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) From 325fd539fc84f0aaa0ceb9d7d3b8718582473dc5 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:22:46 +0200 Subject: [PATCH 34/39] 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) From b4ebddd6540d78a7f977b3fea0261bd575c6ffe2 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:22:47 +0200 Subject: [PATCH 35/39] 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); From 6bcd2960af1b7bacb2f1e710ab0c0b802d900501 Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Wed, 29 Sep 2021 00:22:48 +0200 Subject: [PATCH 36/39] 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) From eec417fd317a95a79257c20b3a1d66d4027549df Mon Sep 17 00:00:00 2001 From: Chris Morgan Date: Thu, 30 Sep 2021 11:24:02 -0500 Subject: [PATCH 37/39] 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) }, From 73e197df1949347bbc1902605b6c7fe8e3b04249 Mon Sep 17 00:00:00 2001 From: Manivannan Sadhasivam Date: Mon, 4 Oct 2021 18:09:26 +0530 Subject: [PATCH 38/39] 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 From fc9e18f9e987ad46722dad53adab1c12148c213c Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Fri, 8 Oct 2021 18:36:40 +0200 Subject: [PATCH 39/39] 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))