Re: [PATCH net-next 6/6] net: phy: dp83869: Fix link up reporting in SGMII bridge mode

From: Romain Gantois
Date: Tue Jul 02 2024 - 05:04:19 EST


On lundi 1 juillet 2024 19:09:40 UTC+2 Andrew Lunn wrote:
> > + if (dp83869->mod_phy) {
> > + ret = phy_read_status(dp83869->mod_phy);
> > + if (ret)
> > + return ret;
>
> Locking? When phylib does this in phy_check_link_status(), we have:
>
> lockdep_assert_held(&phydev->lock);
>
> I don't see anything which takes the downstreams PHY lock.
>
> Is this also introducing race conditions? What happens if the link
> just went down? phy_check_link_status() takes actions. Will they still
> happen when phylib next talks to the downstream PHY? It is probably
> safer to call phy_check_link_status() than phy_read_status().

Given that the phylib state machine will call phy_check_link_status() itself,
I think that this call to phy_read_status() could be dropped entirely and that
dp83869_read_status() could just directly read mod_phy->{link,speed,duplex}.

This raises the question of a potential race condition when reading
mod_phy->{link, speed, duplex}. I haven't seen any kind of locking used in
other parts of the net subsystem when reading these parameters.

Thanks,

--
Romain Gantois, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com