arch/imx9: Correct CONFIG_IMX9_ENET_PHYINIT flag and imx9_phy_boardinitialize

[jlaitine]

Summary

This PR has two commits:

• Correct the configuration flag CONFIG_IMX9_ENET_PHYINIT, which is mistakenly written as CONFIG_IMX9_ENET1_PHYINIT in the Kconfig. Also move it to more proper place in Kconfig.
• Move the imx9_phy_boardinitialize to a later phase in ethernet initialization, to enable usage of sleeps and work-queues in board-specific logic.

I needed this function on a custom board, which needs to separately enable the ethernet phy via an i2c command to another device. While doing this, I found out that the

1. PHY is being reset unnecessarily early in the boot flow, and using i2c or sleep is not possible (without specifying CONFIG_NETDEV_LATEINIT, which shouldn't be necessary just for this).
2. It was not possible to even configure the function into use due to mismatch in the CONFIG flag name
3. I'd like to physically reset/power on the phy again every time the interface is taken up

This PR fixes those issues.

Impact

In theory, affects only imx9 based boards with CONFIG_IMX9_ENET_PHYINIT. Which shouldn't exist, since the flag was not usable due to misspelling it in Kconfig. So essentially, no boards are affected.

Testing

Tested on a custom hardware, which requires explicitly powering on the ethernet phy. After implementing the needed "imx9_phy_boardinitialize" in the board files, and enabling the CONFIG_IMX9_ENET_PHYINIT, I can see that the

• PHY link LED starts working
• Board can communicate with PC over ethernet when connected:

nsh> ping 192.168.202.254
PING 192.168.202.254 56 bytes of data
56 bytes from 192.168.202.254: icmp_seq=0 time=0.0 ms
56 bytes from 192.168.202.254: icmp_seq=1 time=0.0 ms
56 bytes from 192.168.202.254: icmp_seq=2 time=0.0 ms
56 bytes from 192.168.202.254: icmp_seq=3 time=0.0 ms
56 bytes from 192.168.202.254: icmp_seq=4 time=0.0 ms
56 bytes from 192.168.202.254: icmp_seq=5 time=0.0 ms
56 bytes from 192.168.202.254: icmp_seq=6 time=0.0 ms
56 bytes from 192.168.202.254: icmp_seq=7 time=0.0 ms
56 bytes from 192.168.202.254: icmp_seq=8 time=0.0 ms
56 bytes from 192.168.202.254: icmp_seq=9 time=0.0 ms

[acassis]

@jlaitine the ping latency seems incorrect, I think it cannot be 0.0s, is your clock/timer system configured correctly?

[jlaitine]

@jlaitine the ping latency seems incorrect, I think it cannot be 0.0s, is your clock/timer system configured correctly?

Yes, everything related timing is right. Actually, I have never looked into where that latency figure comes from. Pinging the other way (pinging the device from PC), the latency is around 0.5ms:

$ ping 192.168.202.1
PING 192.168.202.1 (192.168.202.1) 56(84) bytes of data.
64 bytes from 192.168.202.1: icmp_seq=1 ttl=64 time=0.394 ms
64 bytes from 192.168.202.1: icmp_seq=2 ttl=64 time=0.570 ms
64 bytes from 192.168.202.1: icmp_seq=3 ttl=64 time=0.502 ms

That has, however, nothing to do with this PR, the link is up and working fine :)

EDIT: Looks like on my system, measuring the ping time works on the systick accuracy, and the systick is 10ms. This is why it shows just 0.0 ms:

priv->start = clock();
...
priv->elapsed = TICK2USEC(clock() - priv->start);

So I am not concerned about that detail.