From: Miquel Raynal <miquel.raynal@bootlin.com> To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> Cc: Tudor Ambarus <tudor.ambarus@microchip.com>, Richard Weinberger <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>, Nicolas Ferre <nicolas.ferre@microchip.com>, Alexandre Belloni <alexandre.belloni@bootlin.com>, Claudiu Beznea <claudiu.beznea@microchip.com>, kernel@pengutronix.de, linux-mtd@lists.infradead.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 08/14] mtd: rawnand: atmel: Warn about failure to unregister mtd device Date: Mon, 6 Jun 2022 15:16:20 +0200 [thread overview] Message-ID: <20220606151620.0282cece@xps-13> (raw) In-Reply-To: <20220603210758.148493-9-u.kleine-koenig@pengutronix.de> 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/
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com> To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>, Vignesh Raghavendra <vigneshr@ti.com>, Tudor Ambarus <tudor.ambarus@microchip.com>, Richard Weinberger <richard@nod.at>, linux-mtd@lists.infradead.org, kernel@pengutronix.de, Claudiu Beznea <claudiu.beznea@microchip.com>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 08/14] mtd: rawnand: atmel: Warn about failure to unregister mtd device Date: Mon, 6 Jun 2022 15:16:20 +0200 [thread overview] Message-ID: <20220606151620.0282cece@xps-13> (raw) In-Reply-To: <20220603210758.148493-9-u.kleine-koenig@pengutronix.de> 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-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-06-06 13:17 UTC|newest] Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-06-03 21:07 [PATCH 00/14] mtd: Fix platform remove callbacks to always return 0 Uwe Kleine-König 2022-06-03 21:07 ` Uwe Kleine-König 2022-06-03 21:07 ` Uwe Kleine-König 2022-06-03 21:07 ` Uwe Kleine-König 2022-06-03 21:07 ` Uwe Kleine-König 2022-06-03 21:07 ` [PATCH 01/14] mtd: hyperbus: Make hyperbus_unregister_device() return void Uwe Kleine-König 2022-06-09 13:10 ` Miquel Raynal 2022-06-03 21:07 ` [PATCH 02/14] mtd: spi-nor: aspeed-smc: Make aspeed_smc_unregister() " Uwe Kleine-König 2022-06-03 21:07 ` Uwe Kleine-König 2022-06-07 9:28 ` Pratyush Yadav 2022-06-07 9:28 ` Pratyush Yadav 2022-06-07 9:54 ` Cédric Le Goater 2022-06-07 9:54 ` Cédric Le Goater 2022-06-03 21:07 ` [PATCH 03/14] mtd: powernv_flash: Warn about failure to unregister mtd device Uwe Kleine-König 2022-06-03 21:07 ` Uwe Kleine-König 2022-06-09 13:09 ` Miquel Raynal 2022-06-09 13:09 ` Miquel Raynal 2022-06-03 21:07 ` [PATCH 04/14] mtd: st-spi_fsm: " Uwe Kleine-König 2022-06-03 21:07 ` [PATCH 05/14] mtd: lpddr2_nvm: " Uwe Kleine-König 2022-06-09 13:09 ` Miquel Raynal 2022-06-03 21:07 ` [PATCH 06/14] mtd: spear_smi: Don't skip cleanup after mtd_device_unregister() failed Uwe Kleine-König 2022-06-09 13:09 ` Miquel Raynal 2022-06-03 21:07 ` [PATCH 07/14] mtd: spear_smi: Drop if with an always false condition Uwe Kleine-König 2022-06-09 13:09 ` Miquel Raynal 2022-06-03 21:07 ` [PATCH 08/14] mtd: rawnand: atmel: Warn about failure to unregister mtd device Uwe Kleine-König 2022-06-03 21:07 ` Uwe Kleine-König 2022-06-06 13:16 ` Miquel Raynal [this message] 2022-06-06 13:16 ` Miquel Raynal 2022-06-06 19:37 ` Uwe Kleine-König 2022-06-06 19:37 ` Uwe Kleine-König 2022-06-07 6:14 ` Miquel Raynal 2022-06-07 6:14 ` Miquel Raynal 2022-06-03 21:07 ` [PATCH 09/14] mtd: rawnand: omap2: Suppress error message after WARN in .remove() Uwe Kleine-König 2022-06-09 13:09 ` Miquel Raynal 2022-06-03 21:07 ` [PATCH 10/14] mtd: rawnand: tegra: Don't skip cleanup after mtd_device_unregister() failed Uwe Kleine-König 2022-06-03 21:07 ` Uwe Kleine-König 2022-06-09 13:09 ` Miquel Raynal 2022-06-09 13:09 ` Miquel Raynal 2022-06-03 21:07 ` [PATCH 11/14] mtd: rawnand: meson: " Uwe Kleine-König 2022-06-03 21:07 ` Uwe Kleine-König 2022-06-03 21:07 ` Uwe Kleine-König 2022-06-09 13:09 ` Miquel Raynal 2022-06-09 13:09 ` Miquel Raynal 2022-06-09 13:09 ` Miquel Raynal 2022-06-03 21:07 ` [PATCH 12/14] mtd: rawnand: meson: Drop cleaning platform data in .remove() Uwe Kleine-König 2022-06-03 21:07 ` Uwe Kleine-König 2022-06-03 21:07 ` Uwe Kleine-König 2022-06-09 13:09 ` Miquel Raynal 2022-06-09 13:09 ` Miquel Raynal 2022-06-09 13:09 ` Miquel Raynal 2022-06-03 21:07 ` [PATCH 13/14] mtd: physmap: Don't skip cleanup after mtd_device_unregister() failed Uwe Kleine-König 2022-06-09 13:09 ` Miquel Raynal 2022-06-03 21:07 ` [PATCH 14/14] mtd: physmap: Drop if with an always false condition Uwe Kleine-König 2022-06-09 13:09 ` Miquel Raynal 2022-06-06 13:18 ` [PATCH 00/14] mtd: Fix platform remove callbacks to always return 0 Miquel Raynal 2022-06-06 13:18 ` Miquel Raynal 2022-06-06 13:18 ` Miquel Raynal 2022-06-06 13:18 ` Miquel Raynal 2022-06-06 13:18 ` Miquel Raynal 2022-06-07 9:32 ` Pratyush Yadav 2022-06-07 9:32 ` Pratyush Yadav 2022-06-07 9:32 ` Pratyush Yadav 2022-06-07 9:32 ` Pratyush Yadav 2022-06-07 9:32 ` Pratyush Yadav 2022-06-07 10:47 ` Miquel Raynal 2022-06-07 10:47 ` Miquel Raynal 2022-06-07 10:47 ` Miquel Raynal 2022-06-07 10:47 ` Miquel Raynal 2022-06-07 10:47 ` Miquel Raynal
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20220606151620.0282cece@xps-13 \ --to=miquel.raynal@bootlin.com \ --cc=alexandre.belloni@bootlin.com \ --cc=claudiu.beznea@microchip.com \ --cc=kernel@pengutronix.de \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-mtd@lists.infradead.org \ --cc=nicolas.ferre@microchip.com \ --cc=richard@nod.at \ --cc=tudor.ambarus@microchip.com \ --cc=u.kleine-koenig@pengutronix.de \ --cc=vigneshr@ti.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.