Re: Ethtool is missing C2C link modes

quoted

As for your comment/question about FW vs linux controiling the HW, the intent here
is to use linux to tell FW where to go based on user input.
How the link is eventually achieved is all in FW.  

quoted

I don't see how that works. ethtool has no APIs around
phy_interface_t.  All ethtool offers is link modes. How do you see
this working?

Correct me if I am wrong but isn't that the role of the driver?  
I expect device driver to translate Ethtool link mode argument and pass it to 
FW via driver-FW handshake (device specific SET/GET functions). 
MAC and PHY config. which includes phy_interface_t for that specific link speed 
is then implicitly handled by FW. No other intervention from user should be 
required.

It is. But if the driver is talking to firmware, it is using whatever
proprietary values defined by the firmware.

It only makes sense to use phy_interface_t for communication between
different Linux components, or uAPI and a Linux component.

To be precise, what I meant by FW will handle phy_interface_t implicitly is that the
*MII selection (from long list I included in a prior post) is automatically done by 
device FW and not via Linux components or APIs. This step of *MII selection or
configuration may have been handled by Linux components historically (legacy 
implementations) but it is no longer the case with device FW capabilities to manage
link we have today (as someone alluded to in a prior post this being the case
even at the onset of 10G era >20 years ago). 

Vijay