xc interface based notifications in ethernet_cfg_if are channel heavy

[shuchitak]

mii_ethernet_server() uses [[ notification ]] and [[ clears_notification ]] functions when the server wants to initiate communication with the client.

XC_NOTIFICATION slave void mac_started();
XC_CLEARS_NOTIFICATION void ack_mac_start();

This notification is required for the mac to receive the current link state after it restarts after an exit() command.

In the current implementation, the phy driver shares the link state with the mac only when there's a change to the link state.

So when the mac restarts after an exit() command, it continues to see the link as down, which means any clients querying the link state from the mac (get_link_state()) would incorrectly see the link as down.

The mac_started() notification is added so the mac can notify the clients when it starts and the clients can optionally acknowledge the notification. The phy driver client on receiving the mac started notification, shares the current link state with the mac.

While this mechanism works and we have a test (test_hw_restart.py) that tests this, the xc interface based notifications are channel heavy. I suspect it uses one extra channel per client on the ethernet_cfg_if interface.

As a result, its currently wrapped in a #if ENABLE_MAC_START_NOTIFICATION so can be enabled selectively for applications. This is far from ideal and wouldn't translate well to dual mac case.

An easy alternative to this could be the phy_driver querying the link state from the mac periodically and updating it if it sees the link state saved in the mac is different from the current link state. This will however cause unnecessary interruptions to the mac from the phy driver which is not ideal.

Alternatively, we could have a dedicated channel between mii_ethernet_server() and dual_dp83826e_phy_driver() on which the server could query the link state but that would mean an API change for both mii_ethernet_server() and dual_dp83826e_phy_driver().

This issue should implement an alternate solution that is

• optimal in terms of channel usage
• doesn't compromise the mac speed from unnecessary interruptions
• is always enabled (no #if ENABLE_MAC_START_NOTIFICATION)