[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230314221334.hvmkowycpyz4juqg@pengutronix.de>
Date: Tue, 14 Mar 2023 23:13:34 +0100
From: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To: Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org, Eric Dumazet <edumazet@...gle.com>,
Shenwei Wang <shenwei.wang@....com>,
Clark Wang <xiaoning.wang@....com>,
NXP Linux Team <linux-imx@....com>, kernel@...gutronix.de,
Jakub Kicinski <kuba@...nel.org>, Wei Fang <wei.fang@....com>,
Paolo Abeni <pabeni@...hat.com>,
"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH net-next 2/9] net: fec: Don't return early on error in
.remove()
On Tue, Mar 14, 2023 at 01:30:35AM +0100, Andrew Lunn wrote:
> > > > - ret = pm_runtime_resume_and_get(&pdev->dev);
> > > > - if (ret < 0)
> > > > - return ret;
> > > regulator_disable() probably does actually work because that is a
> > > different hardware block unaffected by the suspend.
>
> > fec_suspend() calls
> >
> > if (fep->reg_phy && !(fep->wol_flag & FEC_WOL_FLAG_ENABLE))
> > regulator_disable(fep->reg_phy);
>
> There are two different types of suspend here.
>
> pm_runtime_resume_and_get() is about runtime suspend. It calls
> fec_runtime_suspend() which just turns some clocks off/on.
Oh indeed.
I won't resend this series in this cycle with this issue fixed.
Converting all other drivers to .remove_new() will take quite some time
I guess so there is no pressure. If you apply patches 1, 3, 5 - 9 anyhow
that would be great. (Patch 4 depends on this one.) I'll address the fec
driver at a later point in time.
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