Re: [PATCH net] net: phy: add device link between MAC device and MDIO device
From: Maxime Chevallier
Date: Fri Jan 30 2026 - 03:30:00 EST
Hi,
On 30/01/2026 04:41, Wei Fang wrote:
>> On Wed, Jan 28, 2026 at 08:15:01PM -0800, Jakub Kicinski wrote:
>>> On Mon, 26 Jan 2026 18:44:09 +0800 Wei Fang wrote:
>>>> The commit bc66fa87d4fd ("net: phy: Add link between phy dev and mac
>>>> dev") has created a device link between the MAC and the PHY if the
>>>> MAC uses a shared MDIO bus (The MDIO and the MAC are two separate
>> devices).
>>>> Sarosh Hasan tried to change the DL_FLAG_STATELESS flag to
>>>> DL_FLAG_AUTOREMOVE_SUPPLIER to fix the issue [1]. However, the
>>>> solution does not take into account the hot-swappable PHY devices (such as
>> SFP).
>>>> so when the PHY device is unplugged, the MAC driver will
>>>> automatically be removed, which is not the expected behavior.
>>>>
>>>> Therefore, to solve this issue of the shared MDIO bus, we create the
>>>> device link between the MAC device and the MDIO device, rather than
>>>> between the MAC device and the PHY device. And when the shared MDIO
>>>> bus is removed, all MAC drivers that depend on it will also be removed.
>>>
>>> Anyone willing to venture a review tag?
>>
>> No, I don't agrew with the patch.
>>
>
> Is it because of SFP? If so, would the following modification be more
> reasonable, while SFP still follows the previous logic? I'm not sure if
> phydev->sfp_bus_attached can be used to distinguish between SFP
> PHYs and non-SFP PHYs.
If you want to know if the PHY is in an SFP module, you should use
phy_on_sfp() instead :
https://elixir.bootlin.com/linux/v6.18.6/source/include/linux/phy.h#L1766
It's set for this kind of setups :
SFP module
+-----+ +-----------+
| MAC | ---- | PHY |
+-----+ +--\--------+
\
\_ phy_on_sfp(phydev) == true
phydev->sfp_bus_attached is for the media converter user-case :
SFP Module
+-----+ +-----+ +------------+
| MAC | ---- | PHY | ---- | ??? |
+-----+ +--\--+ +------------+
\
\_ phydev->sfp_bus_attached == true
>
> Anyway, this problem has existed for a long time, and I think we should
> find a way to solve it in upstream. If there's a better approach, I can help
> verify it.
Sorry I wasn't available for most part of yesterday for that discussion.
I'll give a try to this patch today, with the above change and let you know
how this goes.
Maxime