[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <10753836.nUPlyArG6x@fw-rgant>
Date: Thu, 13 Nov 2025 10:27:34 +0100
From: Romain Gantois <romain.gantois@...tlin.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>,
"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Maxime Chevallier <maxime.chevallier@...tlin.com>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v2 3/3] net: phy: dp83869: Support 1000Base-X SFP
Hello Andrew,
On Tuesday, 11 November 2025 02:08:05 CET Andrew Lunn wrote:
...
> > + ret = dp83869_configure_mode(phydev, dp83869);
> > + if (ret)
> > + return ret;
> > +
> > + /* Reconfigure advertisement */
> > + if (mutex_trylock(&phydev->lock)) {
> > + ret = dp83869_config_aneg(phydev);
> > + mutex_unlock(&phydev->lock);
>
> Why is it safe to call dp83869_configure_mode() without the lock, but
> dp83869_config_aneg() does need the lock? And what are the
> consequences of not being able to get the lock and so aneg is not
> configured?
Yeah the idea here is that if the LP changes, then the autoneg should be
restarted afterwards. But doing it in the module_insert() callback of the PHY
driver is quite complex as far as locking goes...
Maxime's phy_port series will make quite a bit of SFP code generic and will
conflict with my series, so maybe it's better that I wait for Maxime's series
to be merged before sending v3. Then I can try tackling this in a generic
manner.
Thanks,
--
Romain Gantois, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists