netdev - Re: [PATCH 0/2 net-next] phy: allow flagging a device as internal

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] [day] [month] [year] [list]

Message-ID: <AF578243-D545-41ED-8532-1167B2D35154@freescale.com>
Date:	Tue, 21 May 2013 17:35:35 +0000
From:	Fleming Andy-AFLEMING <afleming@...escale.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
CC:	Florian Fainelli <f.fainelli@...il.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"jogo@...nwrt.org" <jogo@...nwrt.org>
Subject: Re: [PATCH 0/2 net-next] phy: allow flagging a device as internal



On May 21, 2013, at 11:45, "Ben Hutchings" <bhutchings@...arflare.com> wrote:

> 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.


Alas, yes. We have a 10G card that can switch between copper and fiber. But I agree that the field is poorly-defined.

Andy

--
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