[RFC] Expanding ethtool PHY information

[RFC] Expanding ethtool PHY information

[Ben Hutchings]

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.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: [RFC] Expanding ethtool PHY information

[Jeff Garzik]

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

Re: [RFC] Expanding ethtool PHY information

[Krzysztof Halasa]

Ben Hutchings <bhutchings@solarflare.com> writes:

> 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

Perhaps using an ASCII string would be a better approach? Leaving the
old one for compatibility of course.
-- 
Krzysztof Halasa