Hello, this series prepares to make platform remove callbacks return void. Therefor first update them to always return 0. The rationale is that the Linux device model doesn't handle failures on remove and if a remove callback returns an error, it just emits a quite generic error message and still removes the device. Best regards Uwe Uwe Kleine-König (14): mtd: hyperbus: Make hyperbus_unregister_device() return void mtd: spi-nor: aspeed-smc: Make aspeed_smc_unregister() return void mtd: powernv_flash: Warn about failure to unregister mtd device mtd: st-spi_fsm: Warn about failure to unregister mtd device mtd: lpddr2_nvm: Warn about failure to unregister mtd device mtd: spear_smi: Don't skip cleanup after mtd_device_unregister() failed mtd: spear_smi: Drop if with an always false condition mtd: rawnand: atmel: Warn about failure to unregister mtd device mtd: rawnand: omap2: Suppress error message after WARN in .remove() mtd: rawnand: tegra: Don't skip cleanup after mtd_device_unregister() failed mtd: rawnand: meson: Don't skip cleanup after mtd_device_unregister() failed mtd: rawnand: meson: Drop cleaning platform data in .remove() mtd: physmap: Don't skip cleanup after mtd_device_unregister() failed mtd: physmap: Drop if with an always false condition drivers/mtd/devices/powernv_flash.c | 4 +++- drivers/mtd/devices/spear_smi.c | 10 ++-------- drivers/mtd/devices/st_spi_fsm.c | 4 +++- drivers/mtd/hyperbus/hbmc-am654.c | 6 +++--- drivers/mtd/hyperbus/hyperbus-core.c | 8 ++------ drivers/mtd/hyperbus/rpc-if.c | 5 +++-- drivers/mtd/lpddr/lpddr2_nvm.c | 4 +++- drivers/mtd/maps/physmap-core.c | 13 +++---------- drivers/mtd/nand/raw/atmel/nand-controller.c | 5 ++++- drivers/mtd/nand/raw/meson_nand.c | 16 +++------------- drivers/mtd/nand/raw/omap2.c | 6 ++---- drivers/mtd/nand/raw/tegra_nand.c | 5 +---- drivers/mtd/spi-nor/controllers/aspeed-smc.c | 8 ++++---- include/linux/mtd/hyperbus.h | 4 +--- 14 files changed, 37 insertions(+), 61 deletions(-) base-commit: 4b0986a3613c92f4ec1bdc7f60ec66fea135991f -- 2.36.1 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
The only thing that could theoretically fail in that function is mtd_device_unregister(). However it's not supposed to fail and when used correctly it doesn't. So wail loudly if it does anyhow. This matches how other drivers (e.g. nand/raw/nandsim.c) use mtd_device_unregister(). This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> --- drivers/mtd/hyperbus/hbmc-am654.c | 6 +++--- drivers/mtd/hyperbus/hyperbus-core.c | 8 ++------ drivers/mtd/hyperbus/rpc-if.c | 5 +++-- include/linux/mtd/hyperbus.h | 4 +--- 4 files changed, 9 insertions(+), 14 deletions(-) diff --git a/drivers/mtd/hyperbus/hbmc-am654.c b/drivers/mtd/hyperbus/hbmc-am654.c index a3439b791eeb..a6161ce340d4 100644 --- a/drivers/mtd/hyperbus/hbmc-am654.c +++ b/drivers/mtd/hyperbus/hbmc-am654.c @@ -233,16 +233,16 @@ static int am654_hbmc_remove(struct platform_device *pdev) { struct am654_hbmc_priv *priv = platform_get_drvdata(pdev); struct am654_hbmc_device_priv *dev_priv = priv->hbdev.priv; - int ret; - ret = hyperbus_unregister_device(&priv->hbdev); + hyperbus_unregister_device(&priv->hbdev); + if (priv->mux_ctrl) mux_control_deselect(priv->mux_ctrl); if (dev_priv->rx_chan) dma_release_channel(dev_priv->rx_chan); - return ret; + return 0; } static const struct of_device_id am654_hbmc_dt_ids[] = { diff --git a/drivers/mtd/hyperbus/hyperbus-core.c b/drivers/mtd/hyperbus/hyperbus-core.c index 2f9fc4e17d53..4d8047d43e48 100644 --- a/drivers/mtd/hyperbus/hyperbus-core.c +++ b/drivers/mtd/hyperbus/hyperbus-core.c @@ -126,16 +126,12 @@ int hyperbus_register_device(struct hyperbus_device *hbdev) } EXPORT_SYMBOL_GPL(hyperbus_register_device); -int hyperbus_unregister_device(struct hyperbus_device *hbdev) +void hyperbus_unregister_device(struct hyperbus_device *hbdev) { - int ret = 0; - if (hbdev && hbdev->mtd) { - ret = mtd_device_unregister(hbdev->mtd); + WARN_ON(mtd_device_unregister(hbdev->mtd)); map_destroy(hbdev->mtd); } - - return ret; } EXPORT_SYMBOL_GPL(hyperbus_unregister_device); diff --git a/drivers/mtd/hyperbus/rpc-if.c b/drivers/mtd/hyperbus/rpc-if.c index 6e08ec1d4f09..15a0be63ede1 100644 --- a/drivers/mtd/hyperbus/rpc-if.c +++ b/drivers/mtd/hyperbus/rpc-if.c @@ -153,11 +153,12 @@ static int rpcif_hb_probe(struct platform_device *pdev) static int rpcif_hb_remove(struct platform_device *pdev) { struct rpcif_hyperbus *hyperbus = platform_get_drvdata(pdev); - int error = hyperbus_unregister_device(&hyperbus->hbdev); + + hyperbus_unregister_device(&hyperbus->hbdev); rpcif_disable_rpm(&hyperbus->rpc); - return error; + return 0; } static struct platform_driver rpcif_platform_driver = { diff --git a/include/linux/mtd/hyperbus.h b/include/linux/mtd/hyperbus.h index 0ce612428aea..bb6b7121a542 100644 --- a/include/linux/mtd/hyperbus.h +++ b/include/linux/mtd/hyperbus.h @@ -89,9 +89,7 @@ int hyperbus_register_device(struct hyperbus_device *hbdev); /** * hyperbus_unregister_device - deregister HyperBus slave memory device * @hbdev: hyperbus_device to be unregistered - * - * Return: 0 for success, others for failure. */ -int hyperbus_unregister_device(struct hyperbus_device *hbdev); +void hyperbus_unregister_device(struct hyperbus_device *hbdev); #endif /* __LINUX_MTD_HYPERBUS_H__ */ -- 2.36.1 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
The function returns zero unconditionally, so simplify to make it obvious there is no error to handle in the callers. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> --- drivers/mtd/spi-nor/controllers/aspeed-smc.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/mtd/spi-nor/controllers/aspeed-smc.c b/drivers/mtd/spi-nor/controllers/aspeed-smc.c index acfe010f9dd7..bd149104533a 100644 --- a/drivers/mtd/spi-nor/controllers/aspeed-smc.c +++ b/drivers/mtd/spi-nor/controllers/aspeed-smc.c @@ -399,7 +399,7 @@ static ssize_t aspeed_smc_write_user(struct spi_nor *nor, loff_t to, return len; } -static int aspeed_smc_unregister(struct aspeed_smc_controller *controller) +static void aspeed_smc_unregister(struct aspeed_smc_controller *controller) { struct aspeed_smc_chip *chip; int n; @@ -409,13 +409,13 @@ static int aspeed_smc_unregister(struct aspeed_smc_controller *controller) if (chip) mtd_device_unregister(&chip->nor.mtd); } - - return 0; } static int aspeed_smc_remove(struct platform_device *dev) { - return aspeed_smc_unregister(platform_get_drvdata(dev)); + aspeed_smc_unregister(platform_get_drvdata(dev)); + + return 0; } static const struct of_device_id aspeed_smc_matches[] = { -- 2.36.1 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
mtd_device_unregister() shouldn't fail. Wail loudly if it does anyhow. This matches how other drivers (e.g. nand/raw/nandsim.c) use mtd_device_unregister(). By returning 0 in the platform remove callback a generic error message by the device core is suppressed, nothing else changes. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> --- drivers/mtd/devices/powernv_flash.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/devices/powernv_flash.c b/drivers/mtd/devices/powernv_flash.c index 6950a8764815..36e060386e59 100644 --- a/drivers/mtd/devices/powernv_flash.c +++ b/drivers/mtd/devices/powernv_flash.c @@ -270,7 +270,9 @@ static int powernv_flash_release(struct platform_device *pdev) struct powernv_flash *data = dev_get_drvdata(&(pdev->dev)); /* All resources should be freed automatically */ - return mtd_device_unregister(&(data->mtd)); + WARN_ON(mtd_device_unregister(&data->mtd)); + + return 0; } static const struct of_device_id powernv_flash_match[] = { -- 2.36.1 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
mtd_device_unregister() shouldn't fail. Wail loudly if it does anyhow. This matches how other drivers (e.g. nand/raw/nandsim.c) use mtd_device_unregister(). By returning 0 in the platform remove callback a generic error message by the device core is suppressed, nothing else changes. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> --- drivers/mtd/devices/st_spi_fsm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/devices/st_spi_fsm.c b/drivers/mtd/devices/st_spi_fsm.c index 983999c020d6..f1d3266dda06 100644 --- a/drivers/mtd/devices/st_spi_fsm.c +++ b/drivers/mtd/devices/st_spi_fsm.c @@ -2126,7 +2126,9 @@ static int stfsm_remove(struct platform_device *pdev) { struct stfsm *fsm = platform_get_drvdata(pdev); - return mtd_device_unregister(&fsm->mtd); + WARN_ON(mtd_device_unregister(&fsm->mtd)); + + return 0; } #ifdef CONFIG_PM_SLEEP -- 2.36.1 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
mtd_device_unregister() shouldn't fail. Wail loudly if it does anyhow. This matches how other drivers (e.g. nand/raw/nandsim.c) use mtd_device_unregister(). By returning 0 in the platform remove callback a generic error message by the device core is suppressed, nothing else changes. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> --- drivers/mtd/lpddr/lpddr2_nvm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/lpddr/lpddr2_nvm.c b/drivers/mtd/lpddr/lpddr2_nvm.c index 72f5c7b30079..367e2d906de0 100644 --- a/drivers/mtd/lpddr/lpddr2_nvm.c +++ b/drivers/mtd/lpddr/lpddr2_nvm.c @@ -478,7 +478,9 @@ static int lpddr2_nvm_probe(struct platform_device *pdev) */ static int lpddr2_nvm_remove(struct platform_device *pdev) { - return mtd_device_unregister(dev_get_drvdata(&pdev->dev)); + WARN_ON(mtd_device_unregister(dev_get_drvdata(&pdev->dev))); + + return 0; } /* Initialize platform_driver data structure for lpddr2_nvm */ -- 2.36.1 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
If mtd_device_unregister() fails (which it doesn't when used correctly), the resources bound by the nand chip should be freed anyhow as returning an error value doesn't prevent the device getting unbound. Instead use WARN_ON on the return value similar to how other drivers do it. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> --- drivers/mtd/devices/spear_smi.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/mtd/devices/spear_smi.c b/drivers/mtd/devices/spear_smi.c index 24073518587f..f6febe6662db 100644 --- a/drivers/mtd/devices/spear_smi.c +++ b/drivers/mtd/devices/spear_smi.c @@ -1045,7 +1045,7 @@ static int spear_smi_remove(struct platform_device *pdev) { struct spear_smi *dev; struct spear_snor_flash *flash; - int ret, i; + int i; dev = platform_get_drvdata(pdev); if (!dev) { @@ -1060,9 +1060,7 @@ static int spear_smi_remove(struct platform_device *pdev) continue; /* clean up mtd stuff */ - ret = mtd_device_unregister(&flash->mtd); - if (ret) - dev_err(&pdev->dev, "error removing mtd\n"); + WARN_ON(mtd_device_unregister(&flash->mtd)); } clk_disable_unprepare(dev->clk); -- 2.36.1 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
The remove callback is only called after probe completed successfully. In this case platform_set_drvdata() was called with a non-NULL argument and so dev is never NULL. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> --- drivers/mtd/devices/spear_smi.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/drivers/mtd/devices/spear_smi.c b/drivers/mtd/devices/spear_smi.c index f6febe6662db..f58742486d3d 100644 --- a/drivers/mtd/devices/spear_smi.c +++ b/drivers/mtd/devices/spear_smi.c @@ -1048,10 +1048,6 @@ static int spear_smi_remove(struct platform_device *pdev) int i; dev = platform_get_drvdata(pdev); - if (!dev) { - dev_err(&pdev->dev, "dev is null\n"); - return -ENODEV; - } /* clean up for all nor flash */ for (i = 0; i < dev->num_flashes; i++) { -- 2.36.1 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
The Linux device core doesn't intend remove callbacks to fail. If an error code is returned the device is removed anyhow. So wail loudly if the atmel specific remove callback fails and return 0 anyhow to suppress the generic (and little helpful) error message by the device core. Also check the remove callback to actually exist before calling it. That might happen if nc->caps->ops points to atmel_nand_controller_ops. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> --- drivers/mtd/nand/raw/atmel/nand-controller.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c b/drivers/mtd/nand/raw/atmel/nand-controller.c index 6ef14442c71a..bc6ee694f4e2 100644 --- a/drivers/mtd/nand/raw/atmel/nand-controller.c +++ b/drivers/mtd/nand/raw/atmel/nand-controller.c @@ -2629,7 +2629,10 @@ static int atmel_nand_controller_remove(struct platform_device *pdev) { struct atmel_nand_controller *nc = platform_get_drvdata(pdev); - return nc->caps->ops->remove(nc); + if (nc->caps->ops->remove) + WARN_ON(nc->caps->ops->remove(nc)); + + return 0; } static __maybe_unused int atmel_nand_controller_resume(struct device *dev) -- 2.36.1 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
Returning an error value in a platform remove callback results in an error message being emitted by the platform core, but otherwise it doesn't make a difference. After the WARN splat this generic error message doesn't add any value, so return 0 unconditionally Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> --- drivers/mtd/nand/raw/omap2.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/mtd/nand/raw/omap2.c b/drivers/mtd/nand/raw/omap2.c index 58c32a11792e..4a9f2b6c772d 100644 --- a/drivers/mtd/nand/raw/omap2.c +++ b/drivers/mtd/nand/raw/omap2.c @@ -2278,16 +2278,14 @@ static int omap_nand_remove(struct platform_device *pdev) struct mtd_info *mtd = platform_get_drvdata(pdev); struct nand_chip *nand_chip = mtd_to_nand(mtd); struct omap_nand_info *info = mtd_to_omap(mtd); - int ret; rawnand_sw_bch_cleanup(nand_chip); if (info->dma) dma_release_channel(info->dma); - ret = mtd_device_unregister(mtd); - WARN_ON(ret); + WARN_ON(mtd_device_unregister(mtd)); nand_cleanup(nand_chip); - return ret; + return 0; } /* omap_nand_ids defined in linux/platform_data/mtd-nand-omap2.h */ -- 2.36.1 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
If mtd_device_unregister() fails (which it doesn't when used correctly), the resources bound by the nand chip should be freed anyhow as returning an error value doesn't prevent the device getting unbound. Instead use WARN_ON on the return value similar to how other drivers do it. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> --- drivers/mtd/nand/raw/tegra_nand.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/mtd/nand/raw/tegra_nand.c b/drivers/mtd/nand/raw/tegra_nand.c index b36e5260ae27..e12f9f580a15 100644 --- a/drivers/mtd/nand/raw/tegra_nand.c +++ b/drivers/mtd/nand/raw/tegra_nand.c @@ -1223,11 +1223,8 @@ static int tegra_nand_remove(struct platform_device *pdev) struct tegra_nand_controller *ctrl = platform_get_drvdata(pdev); struct nand_chip *chip = ctrl->chip; struct mtd_info *mtd = nand_to_mtd(chip); - int ret; - ret = mtd_device_unregister(mtd); - if (ret) - return ret; + WARN_ON(mtd_device_unregister(mtd)); nand_cleanup(chip); -- 2.36.1 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
If mtd_device_unregister() fails (which it doesn't when used correctly), the resources bound by the nand chip should be freed anyhow as returning an error value doesn't prevent the device getting unbound. Instead use WARN_ON on the return value similar to how other drivers do it. Then meson_nfc_nand_chip_cleanup() returns 0 unconditionally and can be changed to return void which allows further simplification in the remove callback. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> --- drivers/mtd/nand/raw/meson_nand.c | 14 +++----------- 1 file changed, 3 insertions(+), 11 deletions(-) diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c index ac3be92872d0..748e115b0bb7 100644 --- a/drivers/mtd/nand/raw/meson_nand.c +++ b/drivers/mtd/nand/raw/meson_nand.c @@ -1293,26 +1293,21 @@ meson_nfc_nand_chip_init(struct device *dev, return 0; } -static int meson_nfc_nand_chip_cleanup(struct meson_nfc *nfc) +static void meson_nfc_nand_chip_cleanup(struct meson_nfc *nfc) { struct meson_nfc_nand_chip *meson_chip; struct mtd_info *mtd; - int ret; while (!list_empty(&nfc->chips)) { meson_chip = list_first_entry(&nfc->chips, struct meson_nfc_nand_chip, node); mtd = nand_to_mtd(&meson_chip->nand); - ret = mtd_device_unregister(mtd); - if (ret) - return ret; + WARN_ON(mtd_device_unregister(mtd)); meson_nfc_free_buffer(&meson_chip->nand); nand_cleanup(&meson_chip->nand); list_del(&meson_chip->node); } - - return 0; } static int meson_nfc_nand_chips_init(struct device *dev, @@ -1445,11 +1440,8 @@ static int meson_nfc_probe(struct platform_device *pdev) static int meson_nfc_remove(struct platform_device *pdev) { struct meson_nfc *nfc = platform_get_drvdata(pdev); - int ret; - ret = meson_nfc_nand_chip_cleanup(nfc); - if (ret) - return ret; + meson_nfc_nand_chip_cleanup(nfc); meson_nfc_disable_clk(nfc); -- 2.36.1 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
The driver core cares for unsetting platform data (see device_unbind_cleanup()) on remove. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> --- drivers/mtd/nand/raw/meson_nand.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c index 748e115b0bb7..4e6d1a6a19c7 100644 --- a/drivers/mtd/nand/raw/meson_nand.c +++ b/drivers/mtd/nand/raw/meson_nand.c @@ -1445,8 +1445,6 @@ static int meson_nfc_remove(struct platform_device *pdev) meson_nfc_disable_clk(nfc); - platform_set_drvdata(pdev, NULL); - return 0; } -- 2.36.1 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
If mtd_device_unregister() fails (which it doesn't when used correctly), the resources bound by the nand chip should be freed anyhow as returning an error value doesn't prevent the device getting unbound. Instead use WARN_ON on the return value similar to how other drivers do it. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> --- drivers/mtd/maps/physmap-core.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/mtd/maps/physmap-core.c b/drivers/mtd/maps/physmap-core.c index 4f63b8430c71..d433df84a394 100644 --- a/drivers/mtd/maps/physmap-core.c +++ b/drivers/mtd/maps/physmap-core.c @@ -66,7 +66,7 @@ static int physmap_flash_remove(struct platform_device *dev) { struct physmap_flash_info *info; struct physmap_flash_data *physmap_data; - int i, err = 0; + int i; info = platform_get_drvdata(dev); if (!info) { @@ -75,9 +75,7 @@ static int physmap_flash_remove(struct platform_device *dev) } if (info->cmtd) { - err = mtd_device_unregister(info->cmtd); - if (err) - goto out; + WARN_ON(mtd_device_unregister(info->cmtd)); if (info->cmtd != info->mtds[0]) mtd_concat_destroy(info->cmtd); @@ -92,10 +90,9 @@ static int physmap_flash_remove(struct platform_device *dev) if (physmap_data && physmap_data->exit) physmap_data->exit(dev); -out: pm_runtime_put(&dev->dev); pm_runtime_disable(&dev->dev); - return err; + return 0; } static void physmap_set_vpp(struct map_info *map, int state) -- 2.36.1 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
The remove callback is only called after probe completed successfully. In this case platform_set_drvdata() was called with a non-NULL argument and so info is never NULL. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> --- drivers/mtd/maps/physmap-core.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/drivers/mtd/maps/physmap-core.c b/drivers/mtd/maps/physmap-core.c index d433df84a394..85eca6a192e6 100644 --- a/drivers/mtd/maps/physmap-core.c +++ b/drivers/mtd/maps/physmap-core.c @@ -69,10 +69,6 @@ static int physmap_flash_remove(struct platform_device *dev) int i; info = platform_get_drvdata(dev); - if (!info) { - err = -EINVAL; - goto out; - } if (info->cmtd) { WARN_ON(mtd_device_unregister(info->cmtd)); -- 2.36.1 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
Hi Uwe, u.kleine-koenig@pengutronix.de wrote on Fri, 3 Jun 2022 23:07:52 +0200: > The Linux device core doesn't intend remove callbacks to fail. If an > error code is returned the device is removed anyhow. So wail loudly if > the atmel specific remove callback fails and return 0 anyhow to suppress > the generic (and little helpful) error message by the device core. > > Also check the remove callback to actually exist before calling it. That > might happen if nc->caps->ops points to atmel_nand_controller_ops. I believe you got mislead by grepping the code because there is: * struct nand_controller_ops atmel_nand_controller_ops -> this is a NAND-wide controller ops structure * struct atmel_nand_controller_ops atmel_<smtg>_nc_ops -> this is a driver specific structure to provide different registration helpers. The latter always provide a probe and a remove implementation, so I believe the addition if the "if (nc->caps->ops->remove)" check is not relevant, unless I missed something. > This is a preparation for making platform remove callbacks return void. > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > --- > drivers/mtd/nand/raw/atmel/nand-controller.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c b/drivers/mtd/nand/raw/atmel/nand-controller.c > index 6ef14442c71a..bc6ee694f4e2 100644 > --- a/drivers/mtd/nand/raw/atmel/nand-controller.c > +++ b/drivers/mtd/nand/raw/atmel/nand-controller.c > @@ -2629,7 +2629,10 @@ static int atmel_nand_controller_remove(struct platform_device *pdev) > { > struct atmel_nand_controller *nc = platform_get_drvdata(pdev); > > - return nc->caps->ops->remove(nc); > + if (nc->caps->ops->remove) > + WARN_ON(nc->caps->ops->remove(nc)); > + > + return 0; > } > > static __maybe_unused int atmel_nand_controller_resume(struct device *dev) Thanks, Miquèl ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
Hi Folks, u.kleine-koenig@pengutronix.de wrote on Fri, 3 Jun 2022 23:07:44 +0200: > Hello, > > this series prepares to make platform remove callbacks return void. > Therefor first update them to always return 0. The rationale is that the > Linux device model doesn't handle failures on remove and if a remove > callback returns an error, it just emits a quite generic error message > and still removes the device. Tudor, Pratyush, Richard, Vignesh, The series looks good to me (besides the atmel patch), I think it's best to take it directly through mtd/next instead of going through all the different internal branches, please let me know if you disagree with the idea. Cheers, Miquèl > > Best regards > Uwe > > Uwe Kleine-König (14): > mtd: hyperbus: Make hyperbus_unregister_device() return void > mtd: spi-nor: aspeed-smc: Make aspeed_smc_unregister() return void > mtd: powernv_flash: Warn about failure to unregister mtd device > mtd: st-spi_fsm: Warn about failure to unregister mtd device > mtd: lpddr2_nvm: Warn about failure to unregister mtd device > mtd: spear_smi: Don't skip cleanup after mtd_device_unregister() > failed > mtd: spear_smi: Drop if with an always false condition > mtd: rawnand: atmel: Warn about failure to unregister mtd device > mtd: rawnand: omap2: Suppress error message after WARN in .remove() > mtd: rawnand: tegra: Don't skip cleanup after mtd_device_unregister() > failed > mtd: rawnand: meson: Don't skip cleanup after mtd_device_unregister() > failed > mtd: rawnand: meson: Drop cleaning platform data in .remove() > mtd: physmap: Don't skip cleanup after mtd_device_unregister() failed > mtd: physmap: Drop if with an always false condition > > drivers/mtd/devices/powernv_flash.c | 4 +++- > drivers/mtd/devices/spear_smi.c | 10 ++-------- > drivers/mtd/devices/st_spi_fsm.c | 4 +++- > drivers/mtd/hyperbus/hbmc-am654.c | 6 +++--- > drivers/mtd/hyperbus/hyperbus-core.c | 8 ++------ > drivers/mtd/hyperbus/rpc-if.c | 5 +++-- > drivers/mtd/lpddr/lpddr2_nvm.c | 4 +++- > drivers/mtd/maps/physmap-core.c | 13 +++---------- > drivers/mtd/nand/raw/atmel/nand-controller.c | 5 ++++- > drivers/mtd/nand/raw/meson_nand.c | 16 +++------------- > drivers/mtd/nand/raw/omap2.c | 6 ++---- > drivers/mtd/nand/raw/tegra_nand.c | 5 +---- > drivers/mtd/spi-nor/controllers/aspeed-smc.c | 8 ++++---- > include/linux/mtd/hyperbus.h | 4 +--- > 14 files changed, 37 insertions(+), 61 deletions(-) > > base-commit: 4b0986a3613c92f4ec1bdc7f60ec66fea135991f ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
[-- Attachment #1.1: Type: text/plain, Size: 1591 bytes --] On Mon, Jun 06, 2022 at 03:16:20PM +0200, Miquel Raynal wrote: > Hi Uwe, > > u.kleine-koenig@pengutronix.de wrote on Fri, 3 Jun 2022 23:07:52 +0200: > > > The Linux device core doesn't intend remove callbacks to fail. If an > > error code is returned the device is removed anyhow. So wail loudly if > > the atmel specific remove callback fails and return 0 anyhow to suppress > > the generic (and little helpful) error message by the device core. > > > > Also check the remove callback to actually exist before calling it. That > > might happen if nc->caps->ops points to atmel_nand_controller_ops. > > I believe you got mislead by grepping the code because there is: > > * struct nand_controller_ops atmel_nand_controller_ops > -> this is a NAND-wide controller ops structure > > * struct atmel_nand_controller_ops atmel_<smtg>_nc_ops > -> this is a driver specific structure to provide different > registration helpers. > > The latter always provide a probe and a remove implementation, so I > believe the addition if the "if (nc->caps->ops->remove)" check is not > relevant, unless I missed something. You're right. I assume it's easiest for you if I send a v2 with all 14 patches? If you consider this a waste of bytes, please advise. The patches are independant, so it would work if you pick up 1-7 + 9-14, too. Then I'd resend a fixed patch 8 individually. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ | [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 144 bytes --] ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
Hi Uwe, u.kleine-koenig@pengutronix.de wrote on Mon, 6 Jun 2022 21:37:21 +0200: > On Mon, Jun 06, 2022 at 03:16:20PM +0200, Miquel Raynal wrote: > > Hi Uwe, > > > > u.kleine-koenig@pengutronix.de wrote on Fri, 3 Jun 2022 23:07:52 +0200: > > > > > The Linux device core doesn't intend remove callbacks to fail. If an > > > error code is returned the device is removed anyhow. So wail loudly if > > > the atmel specific remove callback fails and return 0 anyhow to suppress > > > the generic (and little helpful) error message by the device core. > > > > > > Also check the remove callback to actually exist before calling it. That > > > might happen if nc->caps->ops points to atmel_nand_controller_ops. > > > > I believe you got mislead by grepping the code because there is: > > > > * struct nand_controller_ops atmel_nand_controller_ops > > -> this is a NAND-wide controller ops structure > > > > * struct atmel_nand_controller_ops atmel_<smtg>_nc_ops > > -> this is a driver specific structure to provide different > > registration helpers. > > > > The latter always provide a probe and a remove implementation, so I > > believe the addition if the "if (nc->caps->ops->remove)" check is not > > relevant, unless I missed something. > > You're right. I assume it's easiest for you if I send a v2 with all 14 > patches? If you consider this a waste of bytes, please advise. The > patches are independant, so it would work if you pick up 1-7 + 9-14, > too. Then I'd resend a fixed patch 8 individually. Please just resend patch 8, I'll handle it. > > Best regards > Uwe > Thanks, Miquèl ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
Hi Uwe, On 03/06/22 11:07PM, Uwe Kleine-König wrote: > The function returns zero unconditionally, so simplify to make it > obvious there is no error to handle in the callers. > > This is a preparation for making platform remove callbacks return void. Cedric recently ported the driver to SPI MEM and it has now hit the linux-next tree [0]. This driver is planned to be removed. Can you please check if the new driver has this issue, and fix it there? [0] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit?id=9c63b846e6df43e5b3d31263f7db545f32deeda3 > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > --- > drivers/mtd/spi-nor/controllers/aspeed-smc.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/mtd/spi-nor/controllers/aspeed-smc.c b/drivers/mtd/spi-nor/controllers/aspeed-smc.c > index acfe010f9dd7..bd149104533a 100644 > --- a/drivers/mtd/spi-nor/controllers/aspeed-smc.c > +++ b/drivers/mtd/spi-nor/controllers/aspeed-smc.c > @@ -399,7 +399,7 @@ static ssize_t aspeed_smc_write_user(struct spi_nor *nor, loff_t to, > return len; > } > > -static int aspeed_smc_unregister(struct aspeed_smc_controller *controller) > +static void aspeed_smc_unregister(struct aspeed_smc_controller *controller) > { > struct aspeed_smc_chip *chip; > int n; > @@ -409,13 +409,13 @@ static int aspeed_smc_unregister(struct aspeed_smc_controller *controller) > if (chip) > mtd_device_unregister(&chip->nor.mtd); > } > - > - return 0; > } > > static int aspeed_smc_remove(struct platform_device *dev) > { > - return aspeed_smc_unregister(platform_get_drvdata(dev)); > + aspeed_smc_unregister(platform_get_drvdata(dev)); > + > + return 0; > } > > static const struct of_device_id aspeed_smc_matches[] = { > -- > 2.36.1 > -- Regards, Pratyush Yadav Texas Instruments Inc. ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
Hi Miquel, On 06/06/22 03:18PM, Miquel Raynal wrote: > Hi Folks, > > u.kleine-koenig@pengutronix.de wrote on Fri, 3 Jun 2022 23:07:44 +0200: > > > Hello, > > > > this series prepares to make platform remove callbacks return void. > > Therefor first update them to always return 0. The rationale is that the > > Linux device model doesn't handle failures on remove and if a remove > > callback returns an error, it just emits a quite generic error message > > and still removes the device. > > Tudor, Pratyush, Richard, Vignesh, > > The series looks good to me (besides the atmel patch), I think it's > best to take it directly through mtd/next instead of going through all > the different internal branches, please let me know if you disagree > with the idea. Patch 2 does not look good to me. It modifies the aspeed-smc driver in drivers/mtd/spi-nor/controllers/ but the driver has been moved to drivers/spi/ in Mark's next branch [0]. The patch would likely conflict with that. [0] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit?id=9c63b846e6df43e5b3d31263f7db545f32deeda3 > > Cheers, > Miquèl > > > > > Best regards > > Uwe > > > > Uwe Kleine-König (14): > > mtd: hyperbus: Make hyperbus_unregister_device() return void > > mtd: spi-nor: aspeed-smc: Make aspeed_smc_unregister() return void > > mtd: powernv_flash: Warn about failure to unregister mtd device > > mtd: st-spi_fsm: Warn about failure to unregister mtd device > > mtd: lpddr2_nvm: Warn about failure to unregister mtd device > > mtd: spear_smi: Don't skip cleanup after mtd_device_unregister() > > failed > > mtd: spear_smi: Drop if with an always false condition > > mtd: rawnand: atmel: Warn about failure to unregister mtd device > > mtd: rawnand: omap2: Suppress error message after WARN in .remove() > > mtd: rawnand: tegra: Don't skip cleanup after mtd_device_unregister() > > failed > > mtd: rawnand: meson: Don't skip cleanup after mtd_device_unregister() > > failed > > mtd: rawnand: meson: Drop cleaning platform data in .remove() > > mtd: physmap: Don't skip cleanup after mtd_device_unregister() failed > > mtd: physmap: Drop if with an always false condition > > > > drivers/mtd/devices/powernv_flash.c | 4 +++- > > drivers/mtd/devices/spear_smi.c | 10 ++-------- > > drivers/mtd/devices/st_spi_fsm.c | 4 +++- > > drivers/mtd/hyperbus/hbmc-am654.c | 6 +++--- > > drivers/mtd/hyperbus/hyperbus-core.c | 8 ++------ > > drivers/mtd/hyperbus/rpc-if.c | 5 +++-- > > drivers/mtd/lpddr/lpddr2_nvm.c | 4 +++- > > drivers/mtd/maps/physmap-core.c | 13 +++---------- > > drivers/mtd/nand/raw/atmel/nand-controller.c | 5 ++++- > > drivers/mtd/nand/raw/meson_nand.c | 16 +++------------- > > drivers/mtd/nand/raw/omap2.c | 6 ++---- > > drivers/mtd/nand/raw/tegra_nand.c | 5 +---- > > drivers/mtd/spi-nor/controllers/aspeed-smc.c | 8 ++++---- > > include/linux/mtd/hyperbus.h | 4 +--- > > 14 files changed, 37 insertions(+), 61 deletions(-) > > > > base-commit: 4b0986a3613c92f4ec1bdc7f60ec66fea135991f > -- Regards, Pratyush Yadav Texas Instruments Inc. ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
Hello, On 6/7/22 11:28, Pratyush Yadav wrote: > Hi Uwe, > > On 03/06/22 11:07PM, Uwe Kleine-König wrote: >> The function returns zero unconditionally, so simplify to make it >> obvious there is no error to handle in the callers. >> >> This is a preparation for making platform remove callbacks return void. > > Cedric recently ported the driver to SPI MEM and it has now hit the > linux-next tree [0]. This driver is planned to be removed. Can you > please check if the new driver has this issue, and fix it there? > > [0] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit?id=9c63b846e6df43e5b3d31263f7db545f32deeda3 It is merged in -rc1 now : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spi-aspeed-smc.c I think aspeed_spi_remove() does what you want there. Thanks, C. >> >> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> >> --- >> drivers/mtd/spi-nor/controllers/aspeed-smc.c | 8 ++++---- >> 1 file changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/mtd/spi-nor/controllers/aspeed-smc.c b/drivers/mtd/spi-nor/controllers/aspeed-smc.c >> index acfe010f9dd7..bd149104533a 100644 >> --- a/drivers/mtd/spi-nor/controllers/aspeed-smc.c >> +++ b/drivers/mtd/spi-nor/controllers/aspeed-smc.c >> @@ -399,7 +399,7 @@ static ssize_t aspeed_smc_write_user(struct spi_nor *nor, loff_t to, >> return len; >> } >> >> -static int aspeed_smc_unregister(struct aspeed_smc_controller *controller) >> +static void aspeed_smc_unregister(struct aspeed_smc_controller *controller) >> { >> struct aspeed_smc_chip *chip; >> int n; >> @@ -409,13 +409,13 @@ static int aspeed_smc_unregister(struct aspeed_smc_controller *controller) >> if (chip) >> mtd_device_unregister(&chip->nor.mtd); >> } >> - >> - return 0; >> } >> >> static int aspeed_smc_remove(struct platform_device *dev) >> { >> - return aspeed_smc_unregister(platform_get_drvdata(dev)); >> + aspeed_smc_unregister(platform_get_drvdata(dev)); >> + >> + return 0; >> } >> >> static const struct of_device_id aspeed_smc_matches[] = { >> -- >> 2.36.1 >> > ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
Hi Pratyush, Uwe, p.yadav@ti.com wrote on Tue, 7 Jun 2022 15:02:36 +0530: > Hi Miquel, > > On 06/06/22 03:18PM, Miquel Raynal wrote: > > Hi Folks, > > > > u.kleine-koenig@pengutronix.de wrote on Fri, 3 Jun 2022 23:07:44 +0200: > > > > > Hello, > > > > > > this series prepares to make platform remove callbacks return void. > > > Therefor first update them to always return 0. The rationale is that the > > > Linux device model doesn't handle failures on remove and if a remove > > > callback returns an error, it just emits a quite generic error message > > > and still removes the device. > > > > Tudor, Pratyush, Richard, Vignesh, > > > > The series looks good to me (besides the atmel patch), I think it's > > best to take it directly through mtd/next instead of going through all > > the different internal branches, please let me know if you disagree > > with the idea. > > Patch 2 does not look good to me. It modifies the aspeed-smc driver in > drivers/mtd/spi-nor/controllers/ but the driver has been moved to > drivers/spi/ in Mark's next branch [0]. The patch would likely conflict > with that. > > [0] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit?id=9c63b846e6df43e5b3d31263f7db545f32deeda3 Right, I believe Uwe is sending per-subsystems series so now that he is aware we can safely drop patch 2. Thanks, Miquèl ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
On Fri, 2022-06-03 at 21:07:58 UTC, =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= wrote: > The remove callback is only called after probe completed successfully. > In this case platform_set_drvdata() was called with a non-NULL argument > and so info is never NULL. > > This is a preparation for making platform remove callbacks return void. > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git mtd/next, thanks. Miquel ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
On Fri, 2022-06-03 at 21:07:57 UTC, =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= wrote: > If mtd_device_unregister() fails (which it doesn't when used correctly), > the resources bound by the nand chip should be freed anyhow as returning > an error value doesn't prevent the device getting unbound. > > Instead use WARN_ON on the return value similar to how other drivers do > it. > > This is a preparation for making platform remove callbacks return void. > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git mtd/next, thanks. Miquel ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
On Fri, 2022-06-03 at 21:07:56 UTC, =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= wrote: > The driver core cares for unsetting platform data (see > device_unbind_cleanup()) on remove. > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git mtd/next, thanks. Miquel ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
On Fri, 2022-06-03 at 21:07:55 UTC, =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= wrote: > If mtd_device_unregister() fails (which it doesn't when used correctly), > the resources bound by the nand chip should be freed anyhow as returning > an error value doesn't prevent the device getting unbound. > > Instead use WARN_ON on the return value similar to how other drivers do > it. Then meson_nfc_nand_chip_cleanup() returns 0 unconditionally and can > be changed to return void which allows further simplification in the > remove callback. > > This is a preparation for making platform remove callbacks return void. > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git mtd/next, thanks. Miquel ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
On Fri, 2022-06-03 at 21:07:54 UTC, =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= wrote: > If mtd_device_unregister() fails (which it doesn't when used correctly), > the resources bound by the nand chip should be freed anyhow as returning > an error value doesn't prevent the device getting unbound. > > Instead use WARN_ON on the return value similar to how other drivers do > it. > > This is a preparation for making platform remove callbacks return void. > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git mtd/next, thanks. Miquel ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
On Fri, 2022-06-03 at 21:07:53 UTC, =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= wrote: > Returning an error value in a platform remove callback results in an error > message being emitted by the platform core, but otherwise it doesn't make > a difference. After the WARN splat this generic error message doesn't add > any value, so return 0 unconditionally > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git mtd/next, thanks. Miquel ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
On Fri, 2022-06-03 at 21:07:51 UTC, =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= wrote: > The remove callback is only called after probe completed successfully. > In this case platform_set_drvdata() was called with a non-NULL argument > and so dev is never NULL. > > This is a preparation for making platform remove callbacks return void. > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git mtd/next, thanks. Miquel ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
On Fri, 2022-06-03 at 21:07:50 UTC, =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= wrote: > If mtd_device_unregister() fails (which it doesn't when used correctly), > the resources bound by the nand chip should be freed anyhow as returning > an error value doesn't prevent the device getting unbound. > > Instead use WARN_ON on the return value similar to how other drivers do > it. > > This is a preparation for making platform remove callbacks return void. > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git mtd/next, thanks. Miquel ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
On Fri, 2022-06-03 at 21:07:49 UTC, =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= wrote: > mtd_device_unregister() shouldn't fail. Wail loudly if it does anyhow. > > This matches how other drivers (e.g. nand/raw/nandsim.c) use > mtd_device_unregister(). > > By returning 0 in the platform remove callback a generic error message > by the device core is suppressed, nothing else changes. > > This is a preparation for making platform remove callbacks return void. > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git mtd/next, thanks. Miquel ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
On Fri, 2022-06-03 at 21:07:47 UTC, =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= wrote: > mtd_device_unregister() shouldn't fail. Wail loudly if it does anyhow. > > This matches how other drivers (e.g. nand/raw/nandsim.c) use > mtd_device_unregister(). > > By returning 0 in the platform remove callback a generic error message > by the device core is suppressed, nothing else changes. > > This is a preparation for making platform remove callbacks return void. > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git mtd/next, thanks. Miquel ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
On Fri, 2022-06-03 at 21:07:45 UTC, =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= wrote: > The only thing that could theoretically fail in that function is > mtd_device_unregister(). However it's not supposed to fail and when > used correctly it doesn't. So wail loudly if it does anyhow. > > This matches how other drivers (e.g. nand/raw/nandsim.c) use > mtd_device_unregister(). > > This is a preparation for making platform remove callbacks return void. > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git mtd/next, thanks. Miquel ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/