smsc95xx driver slow when ethernet cable unplugged

Start with smsc95xx.c and the phylib change in commit 05b35e7eb9a11bbe8102836965e634c04e712c88, then reproduce on a Raspberry Pi 3 with the cable unplugged using ifconfig or ip a. Trace the get_link calls while rtnl_lock() is held and compare with the 5.4 behavior. Done means interface queries no longer take several seconds unplugged while link-up behavior remains acceptable.

Describe the bug

After upgrading to kirkstone and the 5.15 kernel I've noticed the smsc95xx driver is slow when the ethernet cable is unplugged. Running 'ifconfig' or 'ip' can take up to 20 seconds to complete but usually more like 5. Performance is good when the cable is plugged.

Steps to reproduce the behaviour

Unplug ethernet cable
ifconfig or ip a

Device (s)

Raspberry Pi 3 Mod. B

System

OS: kirkstone branch of yocto poky, meta-openembedded, and meta-raspberrypi.

Linux lcm_0AFD 5.15.34-v7 #1 SMP Tue Oct 4 00:13:54 UTC 2022 armv7l GNU/Linux

Logs

No response

Additional context

It looks like this occurred around the 2.0.0 driver version on this commit:

commit 05b35e7eb9a11bbe8102836965e634c04e712c88
Author: Andre Edich andre.edich@microchip.com
Date: Wed Aug 26 13:17:17 2020 +0200

smsc95xx: add phylib support

The ethtool_ops get_link() function changed from usbnet_get_link() to smsc95xx_get_link().

On the current driver version 2.0.0 (commit fe83b18ef954a4b7eb920a40172a58f0c5f5aa8a) changing it back to usbnet_get_link() results in WARN's and is still slow. If I use ethtool_op_get_link() it is fast but it takes a long time to get an IP address when the cable is plugged in as it tries to resolve link status.

The ioctl sent from ifconfig is SIOCGIFCONF. The call stack is, roughly:

net/core/dev_ioctl.c:
int dev_ifconf(struct net *net, struct ifconf __user uifc)
{

/ Loop over the interfaces, and write an info block for each. */
rtnl_lock();
for_each_netdev(net, dev) {

When rtnl_lock() is called I can see multiple calls into get_link in smsc95xx.c where it takes many seconds to determine link status (unplugged) before reporting. Expected behaviour is performance similar to the 5.4 kernel when the driver version was "1.0.6".