From: Maxime Chevallier <maxime.chevallier@bootlin.com>
To: Wei Fang <wei.fang@nxp.com>,
andrew@lunn.ch, hkallweit1@gmail.com, linux@armlinux.org.uk,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, florian.fainelli@broadcom.com,
xiaolei.wang@windriver.com, quic_abchauha@quicinc.com,
quic_sarohasa@quicinc.com
Cc: imx@lists.linux.dev, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 net] net: phy: change devlink flag to AUTOREMOVE_SUPPLIER for non-SFP PHYs
Date: Mon, 2 Feb 2026 12:10:41 +0100 [thread overview]
Message-ID: <267c78c1-4ad2-4f06-be63-0fb506c5134d@bootlin.com> (raw)
In-Reply-To: <20260202054533.539883-1-wei.fang@nxp.com>
Hi Wei,
On 02/02/2026 06:45, Wei Fang wrote:
> For the shared MDIO bus use case, multiple MACs will share the same MDIO
> bus. Therefore, these MACs all depend on this MDIO bus. If this shared
> MDIO bus is removed, all the PHY devices attached to this MDIO bus will
> also be removed. Consequently, the MAC driver should not access the PHY
> device, otherwise, it will lead to some potential crashes. Because the
> corresponding phydev and the mii_bus have been freed, some pointers have
> become invalid.
>
> For example. Abhishek reported a crash issue that occurred if the MDIO
> bus driver was removed first, followed by the MAC driver. The crash log
> is as below.
>
> Call trace:
> __list_del_entry_valid_or_report+0xa8/0xe0
> __device_link_del+0x40/0xf0
> device_link_put_kref+0xb4/0xc8
> device_link_del+0x38/0x58
> phy_detach+0x2c/0x170
> phy_disconnect+0x4c/0x70
> phylink_disconnect_phy+0x6c/0xc0 [phylink]
> stmmac_release+0x60/0x358 [stmmac]
>
> Another example is the i.MX95-15x15 platform which has two ENETC ports.
> When all the external PHYs are managed the EMDIO (the MDIO controller),
> if the enetc driver is removed after the EMDIO driver. Users will see
> the below crash log and the console is hanged.
>
> Call trace:
> _phy_state_machine+0x230/0x36c (P)
> phy_stop+0x74/0x190
> phylink_stop+0x28/0xb8
> enetc_close+0x28/0x8c
> __dev_close_many+0xb4/0x1d8
> netif_close_many+0x8c/0x13c
> enetc4_pf_remove+0x2c/0x84
> pci_device_remove+0x44/0xe8
>
> To address this issue, Sarosh Hasan tried to change the devlink flag to
> DL_FLAG_AUTOREMOVE_SUPPLIER [1], so that the MAC driver will be removed
> along with the PHY driver. However, the solution does not take into
> account the hot-swappable PHY devices (SFP PHYs), so when the PHY device
> is unplugged, the MAC driver will automatically be removed, which is not
> the expected behavior. This issue should not exist for SFP PHYs, so based
> on the Sarosh's patch, the flag is changed to DL_FLAG_AUTOREMOVE_SUPPLIER
> for non-SFP PHYs.
>
> Reported-by: Abhishek Chauhan (ABC) <quic_abchauha@quicinc.com>
> Closes: https://lore.kernel.org/all/d696a426-40bb-4c1a-b42d-990fb690de5e@quicinc.com/
> Link: https://lore.kernel.org/imx/20250703090041.23137-1-quic_sarohasa@quicinc.com/ # [1]
> Fixes: bc66fa87d4fd ("net: phy: Add link between phy dev and mac dev")
> Suggested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> Signed-off-by: Wei Fang <wei.fang@nxp.com>
I gave that patch a test, with the following cases :
- On Macchiatobin (we have PHYs that share an mdiobus).
When unbinding a PHY, the MAC dissapears as well :
#before :
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 2048
link/ether 00:51:82:42:42:00 brd ff:ff:ff:ff:ff:ff
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 2048
link/ether 00:51:82:42:42:01 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 2048
link/ether 00:51:82:42:42:02 brd ff:ff:ff:ff:ff:ff
5: eth3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 2048
link/ether 00:51:82:42:42:03 brd ff:ff:ff:ff:ff:ff
echo f212a600.mdio-mii:08 > /sys/devices/platform/cp0-bus/cp0-bus:bus@f2000000/f212a600.mdio/mdio_bus/f212a600.mdio-mii/f212a600.mdio-mii:08/driver/unbind
The MAC interface correctly disappears, but for some reason a lot of
other interfaces dissapeared as well (only eth0 is left, where I used to
have 4 different interfaces)
# after :
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 2048
link/ether 00:51:82:42:42:00 brd ff:ff:ff:ff:ff:ff
- I also tested the SFP PHY setup on a Cyclone V platform,
and it worked as expected (i.e. MAC didn't disappear under my
feet when removing a Copper SFP, but the devlink was still created when
the module was present) :
# ls /sys/class/devlink/
mdio_bus:i2c:sfp:16--platform:ff702000.ethernet
I don't have time to investigate why my interfaces are dissapearing
on mcbin, but OTHO unbinding the devices manually isn't
something I do very often... It may or may not be related to this patch.
I'll let Russell and Andrew comment more on that as I may
still miss other cases, but as far as I can tell, this looks
OK.
Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
next prev parent reply other threads:[~2026-02-02 11:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-02 5:45 [PATCH v2 net] net: phy: change devlink flag to AUTOREMOVE_SUPPLIER for non-SFP PHYs Wei Fang
2026-02-02 11:10 ` Maxime Chevallier [this message]
2026-02-02 14:25 ` Russell King (Oracle)
2026-02-02 17:38 ` Maxime Chevallier
2026-02-02 18:00 ` Russell King (Oracle)
2026-02-02 18:37 ` Maxime Chevallier
2026-02-03 5:14 ` Wei Fang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=267c78c1-4ad2-4f06-be63-0fb506c5134d@bootlin.com \
--to=maxime.chevallier@bootlin.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=florian.fainelli@broadcom.com \
--cc=hkallweit1@gmail.com \
--cc=imx@lists.linux.dev \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=quic_abchauha@quicinc.com \
--cc=quic_sarohasa@quicinc.com \
--cc=wei.fang@nxp.com \
--cc=xiaolei.wang@windriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox