[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260120153248.0636f1e9@kernel.org>
Date: Tue, 20 Jan 2026 15:32:48 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: linux-phy@...ts.infradead.org, davem@...emloft.net,
maxime.chevallier@...tlin.com, alexandre.torgue@...s.st.com,
mohd.anwar@....qualcomm.com, neil.armstrong@...aro.org,
hkallweit1@...il.com, mcoquelin.stm32@...il.com, netdev@...r.kernel.org,
edumazet@...gle.com, linux-arm-msm@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, vkoul@...nel.org, andrew@...n.ch,
pabeni@...hat.com, andrew+netdev@...n.ch,
linux-stm32@...md-mailman.stormreply.com
Subject: Re: [net-next,05/14] net: stmmac: add stmmac core serdes support
On Tue, 20 Jan 2026 05:04:53 +0000 Russell King (Oracle) wrote:
> By the time phylink_pcs_enable() has been called, the PCS is already
> plumbed in to phylink. It _will_ have phylink_pcs_disable() called on
> it at some point in the future, either by having the PCS displaced
> by another in a subsequent phylink_major_config(), or by a driver
> calling phylink_stop().
>
> If we clean up here, then we will call dwmac_serdes_power_off() twice.
>
> Yes, it's not "nice" but that's the way phylink is right now, and
> without reworking phylink to record that pcs_enable() has failed
> to avoid a subsequent pcs_disable(), and to stop the major config
> (which then potentially causes a whole bunch of other issues). I
> don't even want to think about that horrid scenario at the moment.
Would you mind adding a note to this effect to the commit message
to shut up the bot?
Unless the comment on patch 12 is also incorrect in which case I'll
restore the v1 into patchwork.
Powered by blists - more mailing lists