netdev - 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]

Message-ID: <20160706142121.GI19800@lunn.ch>
Date:	Wed, 6 Jul 2016 16:21:21 +0200
From:	Andrew Lunn <andrew@...n.ch>
To:	Punnaiah Choudary Kalluri <punnaiah.choudary.kalluri@...inx.com>
Cc:	Appana Durga Kedareswara Rao <appanad@...inx.com>,
	"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>,
	Anirudha Sarangi <anirudh@...inx.com>,
	Harini Katakam <harinik@...inx.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>
Subject: Re: [RFC PATCH v2 1/4] Documentation: DT: net: Add Xilinx
 gmiitorgmii converter device tree binding documentation

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

Hi Punnaiah

Use missed some subtlety in my description. I did not call the
GMII2RGMII a PHY device, i called it an MDIO device. These are
different things. Go look at the MDIO subsystem to figure out the
difference.

	Andrew