[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1231879514.3005.31.camel@achroite>
Date: Tue, 13 Jan 2009 20:45:14 +0000
From: Ben Hutchings <bhutchings@...arflare.com>
To: Jeff Garzik <jgarzik@...ox.com>, netdev <netdev@...r.kernel.org>
Subject: [RFC] Expanding ethtool PHY information
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.
--
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
Powered by blists - more mailing lists