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]
Message-ID: <VI1PR04MB1664AB0E483F01F1641059FFE8C00@VI1PR04MB1664.eurprd04.prod.outlook.com>
Date:	Mon, 18 Jan 2016 08:50:18 +0000
From:	Shaohui Xie <shaohui.xie@....com>
To:	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
	Florian Fainelli <f.fainelli@...il.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

> -----Original Message-----
> From: Sebastian Hesselbarth [mailto:sebastian.hesselbarth@...il.com]
> Sent: Monday, January 18, 2016 4:06 PM
> To: Shaohui Xie; Florian Fainelli; Andrew Lunn; shh.xie@...il.com
> Cc: devicetree@...r.kernel.org; netdev@...r.kernel.org; linuxppc-
> dev@...ts.ozlabs.org; davem@...emloft.net; Shaohui Xie
> Subject: Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR
> 
> On 18.01.2016 08:23, Shaohui Xie wrote:
> >>> 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?
> > Right, 'phy-mode' is not a good fit for backplanes, how about a new
> > property like 'backplane-mode' or something, like below:
> 
> Hmm. We already have a speed property for that you can use for 1000, 10000,
> 40000. Leaves the media-type, e.g. copper or whatever.
[S.H] You mean the property 'max-speed'? the problem is the media-type matters.
Please see below.

> 
> Currently, you fail to convince me that it is required to describe the media
> type at all. We have come a long way with different media without describing the
> PHY-to-PHY media type.
> 
> What makes the backplane setup so special?
[S.H] the fsl backplane, e.g. 10GBASE-KR, needs software to handle link training,
It's to train link partner, and trained by link partner parallel.

But if media type is not copper, e.g. optical module, we won't need this.

Thank you!

Shaohui 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ