[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <289c5122-759f-408a-a48a-a3719f0331f9@lunn.ch>
Date: Mon, 1 Jul 2024 19:09:40 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Romain Gantois <romain.gantois@...tlin.com>
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>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 6/6] net: phy: dp83869: Fix link up reporting in
SGMII bridge mode
> + 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().
Andrew
Powered by blists - more mailing lists