[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1369154667.2615.17.camel@bwh-desktop.uk.solarflarecom.com>
Date: Tue, 21 May 2013 17:44:27 +0100
From: Ben Hutchings <bhutchings@...arflare.com>
To: Florian Fainelli <f.fainelli@...il.com>
CC: <davem@...emloft.net>, <netdev@...r.kernel.org>,
<afleming@...escale.com>, <jogo@...nwrt.org>
Subject: Re: [PATCH 0/2 net-next] phy: allow flagging a device as internal
On Tue, 2013-05-21 at 11:37 +0100, Florian Fainelli wrote:
> David, Andy,
>
> This small patch set updates libphy to allow PHY drivers to flag a
> specific PHY device as internal, which is then used to accurately
> report the transceiver type (internal vs external) in ethtool.
>
> As far as I can tell we only have one in-tree driver for the moment
> which is known to be for internal PHYs.
I don't think you should make any change like this until there is proper
documentation of what the 'transceiver' field actually means.
It appears that XCVR_EXTERNAL was originally used for a transceiver
module external to the system, usually connected to an AUI port. The
modern equivalent of that might be SFP+ and similar module slots, but
they're a bit different because the Physical Coding Sublayer is usually
part of the controller.
Many newer drivers are using XCVR_EXTERNAL to indicate that the PHY is a
separate package from the controller, which is what you seem to be doing
here. But nowhere is that specified!
The transceiver field doesn't even really matter much unless the user
has a choice of which to use. Does anyone make boards like that any
more? And it's probably entirely redundant with the port and
phy_address fields in that case, anyway.
Ben.
> Florian Fainelli (2):
> phy: allow drivers to flag a PHY device as internal
> phy: bcm63xx: report Broadcom BCM63xx PHYs as internal
>
> drivers/net/phy/bcm63xx.c | 4 ++--
> drivers/net/phy/phy.c | 2 +-
> drivers/net/phy/phy_device.c | 3 +++
> include/linux/phy.h | 3 +++
> 4 files changed, 9 insertions(+), 3 deletions(-)
>
--
Ben Hutchings, Staff Engineer, Solarflare
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