From: Ben Hutchings <bhutchings@solarflare.com>
To: Jeff Garzik <jgarzik@pobox.com>, netdev <netdev@vger.kernel.org>
Subject: [RFC] Expanding ethtool PHY information
Date: Tue, 13 Jan 2009 20:45:14 +0000 [thread overview]
Message-ID: <1231879514.3005.31.camel@achroite> (raw)
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.
next reply other threads:[~2009-01-13 20:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-13 20:45 Ben Hutchings [this message]
2009-01-14 16:55 ` [RFC] Expanding ethtool PHY information Jeff Garzik
2009-01-14 17:01 ` Krzysztof Halasa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1231879514.3005.31.camel@achroite \
--to=bhutchings@solarflare.com \
--cc=jgarzik@pobox.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).