> -----Original Message----- > From: Sebastian Hesselbarth [mailto:sebastian.hesselbarth@xxxxxxxxx] > Sent: Monday, January 18, 2016 4:06 PM > To: Shaohui Xie; Florian Fainelli; Andrew Lunn; shh.xie@xxxxxxxxx > Cc: devicetree@xxxxxxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx; linuxppc- > dev@xxxxxxxxxxxxxxxx; davem@xxxxxxxxxxxxx; 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 ��.n��������+%������w��{.n����z�{��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
