From: Jeff Garzik <jgarzik@pobox•com>
To: Ben Hutchings <bhutchings@solarflare•com>
Cc: netdev <netdev@vger•kernel.org>
Subject: Re: [RFC] Expanding ethtool PHY information
Date: Wed, 14 Jan 2009 11:55:19 -0500 [thread overview]
Message-ID: <496E18F7.10908@pobox.com> (raw)
In-Reply-To: <1231879514.3005.31.camel@achroite>
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
next prev parent reply other threads:[~2009-01-14 16:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-13 20:45 [RFC] Expanding ethtool PHY information Ben Hutchings
2009-01-14 16:55 ` Jeff Garzik [this message]
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=496E18F7.10908@pobox.com \
--to=jgarzik@pobox$(echo .)com \
--cc=bhutchings@solarflare$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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