netdev - Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR

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

Date:	Fri, 15 Jan 2016 18:59:29 -0800
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
	Shaohui Xie <shaohui.xie@....com>,
	Andrew Lunn <andrew@...n.ch>,
	"shh.xie@...il.com" <shh.xie@...il.com>
Cc:	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
	"davem@...emloft.net" <davem@...emloft.net>,
	Shaohui Xie <Shaohui.Xie@...escale.com>
Subject: Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR

Le 15/01/2016 14:57, Sebastian Hesselbarth a écrit :
> On 15.01.2016 05:01, Shaohui Xie wrote:
>>> -----Original Message-----
>>> From: Andrew Lunn [mailto:andrew@...n.ch]
>>> Sent: Friday, January 15, 2016 12:44 AM
>>> To: shh.xie@...il.com
>>> Cc: devicetree@...r.kernel.org; netdev@...r.kernel.org; linuxppc-
>>> dev@...ts.ozlabs.org; f.fainelli@...il.com; davem@...emloft.net; Shaohui Xie
>>> Subject: Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR
>>>
>>> On Thu, Jan 14, 2016 at 04:23:59PM +0800, shh.xie@...il.com wrote:
>>>> From: Shaohui Xie <Shaohui.Xie@...escale.com>
>>>>
>>>> This commit adds necessary definitions for the PHY layer to recognize
>>>> backplane Ethernet 1000BASE-KX and 10GBASE-KR as valid PHY interfaces,
>>>> "1000base-kx" for 1000BASE-KX, "10gbase-kr" for 10GBASE-KR.
>>>>
>>>> Signed-off-by: Shaohui Xie <Shaohui.Xie@...escale.com>
>>>> ---
>>>> changes in v2:
>>>> new patch.
> 
> Shaohui,
> 
> it would be more useful to describe _what_ is new here compared to v1.
> 
> Anyway:
> 
>>>>  Documentation/devicetree/bindings/net/ethernet.txt | 4 ++--
>>>>  include/linux/phy.h                                | 6 ++++++
>>>>  2 files changed, 8 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/net/ethernet.txt
>>>> b/Documentation/devicetree/bindings/net/ethernet.txt
>>>> index 5d88f37..1166a5c 100644
>>>> --- a/Documentation/devicetree/bindings/net/ethernet.txt
>>>> +++ b/Documentation/devicetree/bindings/net/ethernet.txt
>>>> @@ -11,8 +11,8 @@ The following properties are common to the Ethernet
>>> controllers:
>>>>    the maximum frame size (there's contradiction in ePAPR).
>>>>  - phy-mode: string, operation mode of the PHY interface; supported values are
>>>>    "mii", "gmii", "sgmii", "qsgmii", "tbi", "rev-mii", "rmii",
>>>> "rgmii", "rgmii-id",
>>>> -  "rgmii-rxid", "rgmii-txid", "rtbi", "smii", "xgmii"; this is now a
>>>> de-facto
>>>> -  standard property;
>>>> +  "rgmii-rxid", "rgmii-txid", "rtbi", "smii", "xgmii", "1000base-kx",
>>>> + "10gbase-kr";  this is now a de-facto standard property;
>>>
>>> I know very little about this, so i'm just asking a question. None of the other
>>> interface modes contain a bit rate. So is the bit rate needed for your two new
>>> modes?
>>
>> 1000BASE-KX and 10GBASE-KR are terms in IEEE802.3, so as XGMII and GMII. 
>> There are interfaces could be different bit rates but same types, 
>> e.g. 100BASE-LX10 and 1000BASE-LX10, or 40GBASE-KR4 and 100GBASE-KR4, 
>> having bit rate is clear to represent hardware.
>>
> 
> If you look at the list of possible values for "phy-mode" you'd see that
> none of it describes a PHY-to-PHY connection but all are for MAC-to-PHY
> connections. Also, names above suggest it already: MII is short for
> media _independent_ interface.
> 
> I copy Andrew's concerns and think that neither 10000base-kx nor
> 10gbase-kr belong in the list of phy-mode properties.

I concur with that as well, if the phy connection does not really matter
here, or does not seem like a good fit, maybe we should have a different
property, or just define the hardware interface a little differently?
-- 
Florian