drivers: ethernet: phy: API add ability to read, whether auto-negotiation is enabled or whether a fixed link is used

[clamattia]

Is your enhancement proposal related to a problem? Please describe.
Make it possible to query the phy of whether auto-negotiation is used or whether the link is fixed. This is necessary for some interfaces.

Describe the solution you'd like
Add a function to Ethernet PHY Interface to query this information.

Describe alternatives you've considered
Caller could directly look in the devicetree. But this seems very rigid and fragile at the same time.

Additional context
TBD

[clamattia]

See also #88355

[maass-hamburg]

In general the ethernet mac should not need to know this. In the stm32 eth driver it had to be done, because the hal was also communicating with the phy in its init function, but that will be removed with #88483.

[clamattia]

In general the ethernet mac should not need to know this. In the stm32 eth driver it had to be done, because the hal was also communicating with the phy in its init function, but that will be removed with #88483.

Some protocols require this information. So the application needs to read it.
An example would be to use:

    ok = net_eth_get_hw_config(iface, ETHERNET_CONFIG_TYPE_AUTO_NEG, &cfg);

But it is not implemented in a lot of drivers. And to implement it, I suspect, the mac needs to know this.

[maass-hamburg]

In general the ethernet mac should not need to know this. In the stm32 eth driver it had to be done, because the hal was also communicating with the phy in its init function, but that will be removed with #88483.

Some protocols require this information. So the application needs to read it. An example would be to use:

ok = net_eth_get_hw_config(iface, ETHERNET_CONFIG_TYPE_AUTO_NEG, &cfg);

But it is not implemented in a lot of drivers. And to implement it, I suspect, the mac needs to know this.

thats to get the info from the eth driver not the phy.

It might be a good idea to redirect ETHERNET_CONFIG_TYPE_AUTO_NEG ETHERNET_CONFIG_TYPE_LINK and ETHERNET_CONFIG_TYPE_DUPLEX to the phy, which will then after the link changes inform the ethernet driver via the callback about the change.
Maybe this can be done in a general way to not have duplicated code in every ethernet driver.

[clamattia]

Maybe this can be done in a general way to not have duplicated code in every ethernet driver.

That was my idea behind this Ticket.

Also an option would be to read it directly from the phy via net_eth_get_phy -> the new funcitonality to be defined.

[maass-hamburg]

Also an option would be to read it directly from the phy via net_eth_get_phy -> the new funcitonality to be defined.

I like that option more, because than they could directly use phy_configure_link(). then we could even remove or deprecate ETHERNET_CONFIG_TYPE_AUTO_NEG ETHERNET_CONFIG_TYPE_LINK and ETHERNET_CONFIG_TYPE_DUPLEX.
We could just have to make it possible to activate and deactivate auto negation via phy_configure_link(). Ether we add another parameter to that function (breaking api change) or add a option like NO_AUTONEG to enum phy_link_speed.

[tpambor]

Since #91354 there is support to disable auto-negotiation and with #90652 ETHERNET_CONFIG_TYPE_AUTO_NEG, ETHERNET_CONFIG_TYPE_LINK and ETHERNET_CONFIG_TYPE_DUPLEX have been dropped.

I propose adding a new function to the Ethernet PHY API. This function would expose the advertised speeds, with an empty set indicating that auto-negotiation is disabled.

[maass-hamburg]

@clamattia is this still relevant? I think you are referring the stm32 ethernet driver. It only needed it for the v1 hal api, because the v1 hal api init, was also configuring the phy internally. #88483 should resolve it. Normally the ethernet driver should have no need to know it.

[clamattia]

@clamattia is this still relevant? I think you are referring the stm32 ethernet driver. It only needed it for the v1 hal api, because the v1 hal api init, was also configuring the phy internally. #88483 should resolve it. Normally the ethernet driver should have no need to know it.

Can this information be retrieved using get_phy and then its api? If yes -> this ticket is no longer needed. If no -> this ticket is needed.

This issue wants, that this information is made available to the rest of the system and the application.