Getting IP after a significant delay due to phy_mii_initialize(), MII PHY auto-negotiate sequence, and monitor_work_handler() when using Ethernet and Zephyr 3.7.1.

[ashutoshpandey-eaton]

Describe the bug

Zephyr version: 3.7.1
Driver: eth_stm32_hal.c
PHY driver: phy_mii.c
board: nucleo_h743zi

• In phy_mii.c, inside invoke_link_cb(), the callback (data->cb) is always NULL, so no callback is called.

• It appears eth_stm32_hal.c does not set any PHY link callback, but monitor_work_handler() still runs
  continuously at the frequency of CONFIG_PHY_MONITOR_PERIOD (default 500ms).

• Ethernet connect/disconnect is handled in eth_stm32_hal.c in rx_thread() using net_eth_carrier_on() and net_eth_carrier_off().

Q1: What is the purpose of monitor_work_handler() in this case, since no callback is set?

Q2: If link state is handled in rx_thread(), what is the use of phy_mii_initialize() and the continuously running monitor_work_handler()?

NOTE: If I comment out the content of monitor_work_handler(), I get an IP in the expected time (much faster).

• I am unable to disable the following configs due to dependencies in eth_stm32_hal.c , If I try, I get build/link errors due to references to the PHY device.
  -CONFIG_PHY_GENERIC_MII=n
  CONFIG_ETH_STM32_AUTO_NEGOTIATION_ENABLE=n

Q3:What is the recommended way to avoid the unnecessary delay and redundant polling, given that link state is already handled in the Ethernet driver? I do not want to upgrade Zephyr at this time, but am open to patches

Regression

• This is a regression.

Steps to reproduce

Use zephyr 3.7.1
board nucleo_h743zi/53zi- (where eth_stm32_hal.c and phy_mii.c is used)

Any ethernet example where you are getting IP from dhcp server.

phy_log_1 - Copy.log

Relevant log output

Impact

Annoyance – Minor irritation; no significant impact on usability or functionality.

Environment

Zephyr version: 3.7.1
Driver: eth_stm32_hal.c
PHY driver: phy_mii.c
board: nucleo_h743zi
zephyr-sdk-0.16.9

Additional Context

No response

[maass-hamburg]

it's used in current zephyr since #87593
At that point it was a in between state, before it fully got switched over to the zephyr ethernet phy api.

[juickar]

Hello @ashutoshpandey-eaton, in this version of Zephyr, the monitor_work_handler() function calls the update_link_state() that performs an auto-negotiation process every time we plug the Ethernet cable:
phy_mii.c :

/* Wait for the auto-negotiation process to complete */
do {
	if (timeout-- == 0U) {
		LOG_DBG("PHY (%d) auto-negotiate timedout",
			cfg->phy_addr);
		return -ETIMEDOUT;
	}


	k_sleep(K_MSEC(100));


	if (reg_read(dev, MII_BMSR, &bmsr_reg) < 0) {
		return -EIO;
	}
} while (!(bmsr_reg & MII_BMSR_AUTONEG_COMPLETE));

`
We lose around 1.7 seconds here.

[juickar]

@ashutoshpandey-eaton One way to address this would be to give the ability to skip auto-negotiation if you don't need it

[maass-hamburg]

I would describe this more as a inconvenience, and due to it only effecting old zephyr versions, it probably won't be fixed for them. I always recommend using the newest zephyr version, if you want the best experience. For development I even recommend the current main. Updating is really straight forward as you mostly just have to apply the changes that are mentioned in the migration guide.

Btw in the newest version of zephyr we only restart auto-negotiation from the driver, when we change the configuration.
On init it is very likely, that the default register values match the wanted configuration, so it don't needs to be restarted.