drivers: ethernet: phy_mii: Return -ENOTSUP for fixed-link config

[ofirshe]

Return -ENOTSUP in phy_mii_cfg_link when a fixed-link configuration is set,
indicating that MDIO read/write operations are not supported.

[decsny]

shouldn't it return -ENOTSUP ? The API contract for this specifically says to return -ENOTSUP if not supported with the phy, and sounds like a fixed link does not support configuration

[ofirshe]

@decsny Currently, the fixed-link check is implemented at the PHY driver level rather than in the NXP ENET driver. Given this structure, I don’t see any viable alternative for resolving the issue elsewhere. Moreover, your suggestion to return an error at the PHY level would still prevent the NXP ENET driver from initializing and functioning. Maybe the PHY driver should propagate the fixed-link status to the parent Ethernet driver, preventing it from calling phy_configure_link in such cases. However, this seems like a significant change at the moment.

[decsny]

@decsny Currently, the fixed-link check is implemented at the PHY driver level rather than in the NXP ENET driver. Given this structure, I don’t see any viable alternative for resolving the issue elsewhere. Moreover, your suggestion to return an error at the PHY level would still prevent the NXP ENET driver from initializing and functioning. Maybe the PHY driver should propagate the fixed-link status to the parent Ethernet driver, preventing it from calling phy_configure_link in such cases. However, this seems like a significant change at the moment.

I mean you're saying you're making this ticket because right now the fixed-link phy_mii returns errors due to trying to call mdio functions , so returning -ENOTSUP would be an improvement and not break anything, right?

If the nxp_enet driver does not handle the case where the phy API returns -ENOTSUP (which is specifically distinct in the API as a potentially expected code), then that should be changed in the ethernet driver, probably by considering it to be unexpected and logging a warning (LOG_WRN) but should not cause the ethernet mac device init to error

[ofirshe]

@decsny, Okay, I'll split this into two separate PRs as you suggested.

[ofirshe]

Done.