[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230508171907.4pi6xztf6qfa4zwm@pengutronix.de>
Date: Mon, 8 May 2023 19:19:07 +0200
From: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To: Peppe CAVALLARO <peppe.cavallaro@...com>
Cc: Alexandre TORGUE - foss <alexandre.torgue@...s.st.com>,
Jose Abreu <joabreu@...opsys.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Vladimir Zapolskiy <vz@...ia.com>,
Neil Armstrong <neil.armstrong@...aro.org>,
Kevin Hilman <khilman@...libre.com>, Vinod Koul <vkoul@...nel.org>,
Emil Renner Berthing <kernel@...il.dk>,
Samin Guo <samin.guo@...rfivetech.com>,
Chen-Yu Tsai <wens@...e.org>,
Jernej Skrabec <jernej.skrabec@...il.com>,
Samuel Holland <samuel@...lland.org>,
Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@...hiba.co.jp>,
Matthias Brugger <matthias.bgg@...il.com>,
"linux-oxnas@...ups.io" <linux-oxnas@...ups.io>,
Bhupesh Sharma <bhupesh.sharma@...aro.org>,
Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-sunxi@...ts.linux.dev" <linux-sunxi@...ts.linux.dev>,
"linux-mediatek@...ts.infradead.org" <linux-mediatek@...ts.infradead.org>,
NXP Linux Team <linux-imx@....com>,
"kernel@...gutronix.de" <kernel@...gutronix.de>,
Simon Horman <simon.horman@...igine.com>,
"linux-amlogic@...ts.infradead.org" <linux-amlogic@...ts.infradead.org>,
Jerome Brunet <jbrunet@...libre.com>,
Fabio Estevam <festevam@...il.com>,
"linux-stm32@...md-mailman.stormreply.com" <linux-stm32@...md-mailman.stormreply.com>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
Subject: Re: [PATCH net-next v2 01/11] net: stmmac: Make
stmmac_pltfr_remove() return void
Hello,
On Mon, May 08, 2023 at 02:47:36PM +0000, Peppe CAVALLARO wrote:
> Thx for this patch train, maybe I missed the cover letter. In my
> opinion the proposed change is intrusive but I can accept. It could be
> great to enhance the platform remove functions to fail in case of an
> expected case occurs.
Not sure I understand what you want. platform_remove() (i.e. the caller
of the remove callback) emits a warning if .remove() returns an value !=
0.
In the Linux driver model remove functions are not supposed to fail. The
most usual case for a driver unbind (aka remove) is that the device in
question disappeared (think hotplug). There is no value in failing, what
should happen if the driver fails? There is no chance to reenter
.remove() as some resources might already be freed.
> + .remove_new = stmmac_pltfr_remove,
>
> To be honest, I do not like to see: ".remove_new" as hook
.remove_new() is not here to say. Once all drivers are converted,
.remove() is changed to get the same semantics as .remove_new() has now
and then after all drivers are converted back to .remove() .remove_new()
will be dropped. See 5c5a7680e67ba6fbbb5f4d79fa41485450c1985c for some
more details.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists