Re: [RFC] Expanding ethtool PHY information

[Jeff Garzik <jgarzik@pobox.com>]

Ben Hutchings wrote:
> The set of port types reported through the ethtool API is looking a bit
> limited:
> 
> /* Which connector port. */
> #define PORT_TP			0x00
> #define PORT_AUI		0x01
> #define PORT_MII		0x02
> #define PORT_FIBRE		0x03
> #define PORT_BNC		0x04
> 
> There are of course many different types of fibre and several different
> types of slot for fibre transceivers.  Also there are other copper-wire
> types not included - at least CX4 and KX4.  This is even before we
> consider non-Ethernet devices which are starting to support some of the
> ethtool API.
> 
> This probably doesn't matter for *setting* port type at the moment, as
> few devices other than 10 megabit Ethernet NICs allow software to select
> between different port types.  However it does mean that other port
> types cannot be reported correctly.  At the least, I think we could do
> with a PORT_OTHER.  Similarly for the supported port type flags.
> 
> Other PHY information that seems worth adding:
> - link partner abilities (ethtool_cmd)
> - MDIO support: none, clause 22, clause 45 (ethtool_drvinfo)
> - PHY firmware version (ethtool_drvinfo?)
> 
> What do you think of these?  Obviously it's easy to add these to the
> interface but the structures are filling up and extending them with new
> ethtool operations has a cost.

It's an interesting question.  The port types are really a legacy detail 
left over from the ancient days.

I do agree that other PHY information is worth adding, but my initial 
reaction is to make current drivers PORT_OTHER, and then provide a 
separate avenue for better defining what 'other' means for that specific 
driver/hardware.

	Jeff