From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Lunn Subject: Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR Date: Fri, 22 Jan 2016 15:38:12 +0100 Message-ID: <20160122143812.GP9991@lunn.ch> References: <569C9CD2.10301@gmail.com> <20160118151500.GD923@lunn.ch> <20160121211250.GK9991@lunn.ch> <56A1F5AB.6090606@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sebastian Hesselbarth , Florian Fainelli , "shh.xie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org" , "davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org" To: Shaohui Xie Return-path: Content-Disposition: inline In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: netdev.vger.kernel.org > 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html