netdev - RE: [PATCH] net: phy: adds backplane driver for Freescale's PCS PHY

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:	Tue, 22 Dec 2015 12:33:35 +0000
From:	Shaohui Xie <shaohui.xie@....com>
To:	Andrew Lunn <andrew@...n.ch>
CC:	"shh.xie@...il.com" <shh.xie@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"f.fainelli@...il.com" <f.fainelli@...il.com>,
	Xie Shaohui-B21989 <Shaohui.Xie@...escale.com>
Subject: RE: [PATCH] net: phy: adds backplane driver for Freescale's PCS PHY

> > I did missed the device tree binding documentation.
> > This driver expected a property "lane-instance" in mdio bus node, and
> > "lane-handle" and "lane-range" properties in phy node.
> >
> > The "lane-instance" indicates what the phy should be probed as,
> > 1000BASE-KX or 10GBASE-KR, seems phy node is a better place than mdio
> > bus node to hold this property, maybe a better name "phy-mode" should
> be used?
> 
> Ideally you want all the properties in the phy node. It can get
> complicated, if you have an mdio mux in the chain. Extending phy-mode
> would make, rather than adding a new property.
[S.H] Yes, phy-mode is a better choice.

> 
> >
> > The "lane-handle" pointed to a serdes node which looks like below:
> > E.g. in arch/powerpc/boot/dts/fsl/t4240si-post.dtsi:
> >
> >         serdes: serdes@...00 {
> >                 compatible = "fsl,t4240-serdes";
> >                 reg        = <0xea000 0x4000>;
> >         };
> >
> > The "lane-handle" property would be: lane-handle = <&serdes>;
> 
> There does not appear to be a driver which uses fsl,t4240-serdes?  Is
> there a driver for it? Ah, this is the driver right? It maps the io space
> and uses the registers in that space.
[S.H] There is no driver for fsl,t4240-serdes or any serdes, there are 
many SoCs have a serdes node (grep -r serdes arch/powerpc/boot/dts/).
Only some SoCs can support 1G-KX or 10G-KR, e.g. T4240, T2080, T1024, T1040.
Serdes may be different on different SoCs.

The phy driver needs to configure lane control registers at runtime 
to tune lane signal, but lane control registers are only a small part 
of serdes, there are many other registers for different functions.
It's not a driver for serdes.

> 
> So there is an architectural question. Should there be a separate serdes
> driver, or is it O.K. to include the serdes driver within the phy driver?
[S.H] A serdes driver might be too much, the phy driver only needs to use
Some lane control registers.

> 
> Is the PHY embedded inside the Soc? Or is it discrete? Could the same phy
> be used with a different MAC/serdes interface?
[S.H] Yes, the PHY embedded inside the SoC, each MAC has an internal MDIO 
Controller to access the internal PCS PHY, the same phy cannot be used with
a different MAC/serdes interface.

Thanks,
Shaohui
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html