netdev - Re: [RFC fs_enet: Convert MII bitbang driver to use GPIO lib

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: <20080422153631.GA30309@polina.dev.rtsoft.ru>
Date:	Tue, 22 Apr 2008 19:36:31 +0400
From:	Anton Vorontsov <avorontsov@...mvista.com>
To:	Laurent Pinchart <laurentp@...-semaphore.com>
Cc:	Scott Wood <scottwood@...escale.com>, linuxppc-dev@...abs.org,
	netdev@...r.kernel.org
Subject: Re: [RFC fs_enet: Convert MII bitbang driver to use GPIO lib

On Tue, Apr 22, 2008 at 05:21:49PM +0200, Laurent Pinchart wrote:
> On Tuesday 22 April 2008 17:08, Scott Wood wrote:
> > On Tue, Apr 22, 2008 at 10:55:06AM +0200, Laurent Pinchart wrote:
> > > On Monday 21 April 2008 19:56, Scott Wood wrote:
> > > > The memory-constrained platform I had in mind was 8xx, which doesn't use
> > > > bitbanged MDIO.  It might nice to keep the gpiolib bit separate to avoid
> > > > situations such as ep8248e where mdiobb would be the only thing
> > > > requiring a gpiolib binding, though -- but it shouldn't be two separate
> > > > bitbang drivers, just the existing bitbang driver plus some glue code
> > > > that binds it to gpiolib.
> > > 
> > > I would be fine with that if the glue code wasn't 90% of the whole driver. 
> > > There is really little (not to say nothing) that can be shared between the 
> > > two drivers.
> > 
> > I think we're thinking of a different pair of drivers...  I thought you
> > were talking about duplicating drivers/net/phy/mdio-bitbang.c, not
> > drivers/net/fs_enet/mii-bitbang.c.
> 
> I don't plan to touch drivers/net/phy/mdio-bitbang.c at all, it does its job 
> well enough.
> 
> As the openfirmware + gpio + mdio driver might benefit non-powerpc platforms, 
> I plan to create a new driver (probably drivers/net/phy/mdio-ofgpio.c) that 
> mostly ports drivers/net/fs_enet/mii-bitbang.c to the gpiolib (this replaces 
> around 90% of the code).
> 
> If both drivers/net/fs_enet/mii-bitbang.c and drivers/net/phy/mdio-ofgpio.c 
> must live together, I'll have a problem in 
> drivers/net/fs_enet/fs_enet-main.c. The net device probing code searches the 
> device tree for an associated PHY, and creates a PHY id from the PHY node. As 
> the id will be generated from different bus ids in the two mdio drivers (the 
> bus number is the register address for drivers/net/fs_enet/mii-bitbang.c, and 
> is the gpio index for drivers/net/phy/mdio-ofgpio.c), things will break.
> 
> Any idea regarding how to get rid of that fs_enet/mii-bitbang hardcoded 
> dependency ?

Hm... PHYs are having bus_id equal to MDIOBUS:PHYID, for example
e0024520:02, see fs_enet-main.c find_phy() and fs_init_phy():

        data = of_get_property(np, "phy-handle", &len);
        phynode = of_find_node_by_phandle(*data);
        mdionode = of_get_parent(phynode);
        ret = of_address_to_resource(mdionode, 0, &res);
        data = of_get_property(phynode, "reg", &len);
        snprintf(fpi->bus_id, 16, PHY_ID_FMT, res.start, *data);
...
	phydev = phy_connect(dev, fep->fpi->bus_id, &fs_adjust_link, 0,
		PHY_INTERFACE_MODE_MII);

So in the device tree you could do this:

mdio@<GPIO bank addr> {
	compatible = "linux,mdio-gpio";
	...
	phy123: ethernet-phy@2 {
		reg = <2>;
		device_type = "ethernet-phy";
	};
};

ethernet@... {
	...
	compatible = "fs_enet";
	...
	phy-handle = <&phy123>;
};

And fs_enet will match mdio-ofgpio driver.

-- 
Anton Vorontsov
email: cbouatmailru@...il.com
irc://irc.freenode.net/bd2
--
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