Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 26 Jul 2023 08:53:57 +0200
From:   Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= <u.kleine-koenig@pengutronix.de>
To:     Yangtao Li <frank.li@vivo.com>
Cc:     Adrian Hunter <adrian.hunter@intel.com>,
        Ulf Hansson <ulf.hansson@linaro.org>,
        linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 25/61] mmc: f-sdh30: Convert to platform remove
 callback returning void
Message-ID: <20230726065357.afriboprvkup5kiw@pengutronix.de>
References: <20230726040041.26267-1-frank.li@vivo.com>
 <20230726040041.26267-25-frank.li@vivo.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="lybcthqmrubegsjn"
Content-Disposition: inline
In-Reply-To: <20230726040041.26267-25-frank.li@vivo.com>
Precedence: bulk


--lybcthqmrubegsjn
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 26, 2023 at 12:00:05PM +0800, Yangtao Li wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>=20
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>=20
> Cc: Uwe Kleine-K=F6nig <u.kleine-koenig@pengutronix.de>
> Signed-off-by: Yangtao Li <frank.li@vivo.com>
> Acked-by: Uwe Kleine-K=F6nig <u.kleine-koenig@pengutronix.de>
> ---
>  drivers/mmc/host/sdhci_f_sdh30.c | 8 +++-----
>  1 file changed, 3 insertions(+), 5 deletions(-)
>=20
> diff --git a/drivers/mmc/host/sdhci_f_sdh30.c b/drivers/mmc/host/sdhci_f_=
sdh30.c
> index b01ffb4d0973..840084ee72e6 100644
> --- a/drivers/mmc/host/sdhci_f_sdh30.c
> +++ b/drivers/mmc/host/sdhci_f_sdh30.c
> @@ -206,7 +206,7 @@ static int sdhci_f_sdh30_probe(struct platform_device=
 *pdev)
>  	return ret;
>  }
> =20
> -static int sdhci_f_sdh30_remove(struct platform_device *pdev)
> +static void sdhci_f_sdh30_remove(struct platform_device *pdev)
>  {
>  	struct sdhci_host *host =3D platform_get_drvdata(pdev);
>  	struct f_sdhost_priv *priv =3D sdhci_f_sdhost_priv(host);
> @@ -216,8 +216,6 @@ static int sdhci_f_sdh30_remove(struct platform_devic=
e *pdev)
>  	clk_disable_unprepare(priv->clk_iface);
> =20
>  	sdhci_pltfm_unregister(pdev);
> -
> -	return 0;
>  }

While looking in more detail into this series I noticed a problem in
this driver. (The patch is fine, and so is my Ack.)

The order of function calls in sdhci_f_sdh30_remove is wrong. It first
reasserts the reset and disables clocks and only then unregisters the
sdhci-host which should stay functional until sdhci_remove_host() (called
by sdhci_pltfm_unregister()) completes.

Best regards
Uwe

--=20
Pengutronix e.K.                           | Uwe Kleine-K=F6nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

--lybcthqmrubegsjn
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEP4GsaTp6HlmJrf7Tj4D7WH0S/k4FAmTAwwQACgkQj4D7WH0S
/k5/9Qf/ZCJznZ4ncxfHfX/h7tqjAeMzmN3IOzOka0ZL0Lgkvt2LSEufX5AEQ4d5
yYJRYQUjkco7xvctkyGr2UavRU73z5RlLBVtfN2GU2QjSamh1/0E0F5goOAc7sdK
Ge/34MlYEQwfdjJVmg/3VAA8bRQ2YfrcTOzZv5fcnTKHoROJzKOtWczNpFh4izy7
88YEhX//WtIBU8iqlBngvQR+i5dOfPWCh2pLAdOJPFDWPA5ZlxXz6yGEY+b/Cfmv
CyQe9dmzK9rtn701YYwA44AXWm/Hw9cYsAaiGQtBr2+4FVymfIavuOHlblSo6waX
e+g/Mb9X5rMVyC6eaRp5lmWy8m820w==
=DoOc
-----END PGP SIGNATURE-----

--lybcthqmrubegsjn--