netdev - Re: [RFC] Expanding ethtool PHY information

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <496E18F7.10908@pobox.com>
Date:	Wed, 14 Jan 2009 11:55:19 -0500
From:	Jeff Garzik <jgarzik@...ox.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
CC:	netdev <netdev@...r.kernel.org>
Subject: Re: [RFC] Expanding ethtool PHY information

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




--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html