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]

Message-ID: <20151222104302.GB2373@lunn.ch>
Date:	Tue, 22 Dec 2015 11:43:02 +0100
From:	Andrew Lunn <andrew@...n.ch>
To:	Shaohui Xie <shaohui.xie@....com>
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.

> 
> 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.

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?

Is the PHY embedded inside the Soc? Or is it discrete? Could the same
phy be used with a different MAC/serdes interface?

    Andrew
--
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