[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160122143812.GP9991@lunn.ch>
Date: Fri, 22 Jan 2016 15:38:12 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Shaohui Xie <shaohui.xie@....com>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
"shh.xie@...il.com" <shh.xie@...il.com>,
"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>
Subject: Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR
> The reason I mentioned maybe I should put the backplane property in
> fsl's binding is because the backplane implementation is really
> vendor specific, it's heavily relay how hardware implements the
> feature, maybe another vendor's hardware only needs a boolean
> property for driver to tell it should work in backplane, hardware
> can deal with different modes, or even no any special property
> needed if the hardware is strong enough to handle any connections, I
> cannot assume. But I know what fsl's hardware needs to support
> backplane.
This is the key point really. We don't really care about the Freescale
PCS. We want a generic solution for 1000BASE-KX and 10GBASE-KR,
independent of who makes it, Marvell, Micrel, Broadcom, or Acme.
So, what generic properties are needed for 1000BASE-KX and 10GBASE-KR?
Properties that most/all manufactures are likely to need?
Andrew
Powered by blists - more mailing lists