linux-kernel - RE: [RFC PATCH v2 1/4] Documentation: DT: net: Add Xilinx gmiitorgmii converter device tree binding documentation

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, 26 Jul 2016 15:09:19 +0000
From:	Appana Durga Kedareswara Rao <appana.durga.rao@...inx.com>
To:	Andrew Lunn <andrew@...n.ch>
CC:	"robh+dt@...nel.org" <robh+dt@...nel.org>,
	"mark.rutland@....com" <mark.rutland@....com>,
	Michal Simek <michals@...inx.com>,
	Soren Brinkmann <sorenb@...inx.com>,
	"nicolas.ferre@...el.com" <nicolas.ferre@...el.com>,
	"f.fainelli@...il.com" <f.fainelli@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Punnaiah Choudary Kalluri <punnaia@...inx.com>
Subject: RE: [RFC PATCH v2 1/4] Documentation: DT: net: Add Xilinx
 gmiitorgmii converter device tree binding documentation

Hi Andrew,

	Thanks for the inputs...

> >
> > > > Hi Kedareswara
> > > >
> > > > So looking at the device tree, you have the gmiitorgmii as an mdio
> > > > device. It will get probed as an mdio device, and from that you
> > > > know the address on the bus. However, your driver does not
> > > > actually do this. xilinx_gmii2rgmii.c is just a library of two
> > > > functions, and does not use any of this device tree information.
> > > > You device tree binding is completely bogus.
> > > >
> > > > What i think is a much more logical structure, and fits the
> > > > hardware, which is what DT is all about, is to make your driver an mdio
> driver.
> > > > Also, have a phy-handle pointing to the PHY in the gmii_to_rgmii node.
> > > > You then no longer need the exported gmii2rgmii_phyprobe() function.
> > > >
> > > > Next, you want gmiitorgmii driver to register a phy. The MAC
> > > > driver can then look this up using phy-handle:
> > > >
> > > >        mdio {
> > > >                 #address-cells = <1>;
> > > >                 #size-cells = <0>;
> > > >
> > > >                 phy: ethernet-phy@0 {
> > > >                         reg = <0>;
> > > >                 };
> > > >
> > > >                 gmii_to_rgmii: gmii-to-rgmii@8 {
> > > >                         compatible = "xlnx,gmiitorgmii";
> > > >                         reg = <8>;
> > > > 			phy-handle = <&phy>;
> > > >                 };
> > > >        };
> > >
> > >
> > > Thanks for your inputs initially we too thought the similar
> > > implementation But the GMII2RGMII converter contains only one
> > > register and it is  not compatible to the standard ethernet MII
> > > interface. Also it doesn't have a standard VID and PID registers So,
> > > during the mdio bus scan, this device
> > will
> > > not appear.

I tried to implement the driver as you suggested but there are few limitations in this
Implementation please correct me if my understanding is wrong...

The device-tree will look like below...
        mdio {
                #address-cells = <1>;
                 #size-cells = <0>;
                 phy: ethernet-phy@0 {
                         reg = <0>;
                 };
                 gmii_to_rgmii: gmii-to-rgmii@8 {
                         compatible = "xlnx,gmiitorgmii";
                         reg = <8>;
		phy-handle = <&phy>;
                 };
      };

The MAC driver does the below.
	---> It creates a MDIO device for the gmii_to_rgmii node.
	---> It creates a PHY device for the External PHY node.

The GMII2RGMII driver does the below.
	1) It registers the gmii_to_rgmii node as a MDIO driver.
	It contains the external phy as a phy-handle
	2) Register a PHY Driver.
	---> Register it as a phy driver (phy_register_driver): 
	        For this implementation the converter won't have any VID or DID(PHY register 2 and 3)  
	---> Register phy using of_phy_connect call: 
	       For this implementation needed a netdev pointer to pass it to the of_phy_connect call.
	      (Need to allocate a network device during probe and need to register it as netdev) 
		
	For the 2nd one implement I am facing above limitations...
	Please correct me if my understanding is wrong...

Regards,
Kedar.