netdev - Re: [PATCH 2/2] fs_enet: MDIO on GPIO support

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: <200806261321.24338.laurentp@cse-semaphore.com>
Date:	Thu, 26 Jun 2008 13:21:23 +0200
From:	Laurent Pinchart <laurentp@...-semaphore.com>
To:	linuxppc-dev@...abs.org
Cc:	Jeff Garzik <jgarzik@...ox.com>,
	Scott Wood <scottwood@...escale.com>, vbordug@...mvista.com,
	netdev@...r.kernel.org
Subject: Re: [PATCH 2/2] fs_enet: MDIO on GPIO support

Jeff, Scott,

On Wednesday 18 June 2008 17:16, Laurent Pinchart wrote:
> On Wednesday 18 June 2008 17:00, Jeff Garzik wrote:
> > Laurent Pinchart wrote:
> > > Hi Scott,
> > > 
> > > On Monday 16 June 2008 18:34, Scott Wood wrote:
> > >> On Mon, Jun 16, 2008 at 10:57:02AM +0200, Laurent Pinchart wrote:
> > >>> On Monday 26 May 2008 11:53, Laurent Pinchart wrote:
> > >>>> Port the fs_enet driver to support the MDIO on GPIO driver for PHY
> > >>>> access in addition to the mii-bitbang driver.
> > >>> Now that 1/2 has been applied by Jeff, could this one make it to 
> > >>> powerpc-next ?
> > >> This patch should probably go through Jeff as well...
> > > 
> > > Jeff, what's your opinion on this ?
> > > 
> > >> Acked-by: Scott Wood <scottwood@...escale.com>
> > >>
> > >>>> -	data = of_get_property(phynode, "reg", &len);
> > >>>> -	if (!data || len != 4)
> > >>>> -		goto out_put_mdio;
> > >>>> +	bus_id = of_get_gpio(mdionode, 0);
> > >>>> +	if (bus_id < 0) {
> > >>>> +		struct resource res;
> > >>>> +		ret = of_address_to_resource(mdionode, 0, &res);
> > >>>> +		if (ret)
> > >>>> +			goto out_put_mdio;
> > >>>> +		bus_id = res.start;
> > >>>> +	}
> > >>>>  
> > >>>> -	snprintf(fpi->bus_id, 16, "%x:%02x", res.start, *data);
> > >>>> +	snprintf(fpi->bus_id, 16, "%x:%02x", bus_id, *data);
> > 
> > What are the patch dependencies, if any?
> > 
> > My general rule is, anytime I see 80%+ of the patch dealing with 
> > arch-specific API functions (such as OF resource stuff), I tend to 
> > prefer that goes via an arch tree.
> > 
> > If it's a networking change, of course I'd prefer it came in my direction.
> 
> The patch modifies the way the Freescale SoC fs_enet driver computes the PHY 
> bus_id field when it connects to a PHY.
> 
> The 'legacy' binding method was to use the MDIO general purpose I/O register 
> address to identify the mii bus. My first patch (OpenFirmware GPIO based MDIO 
> bitbang driver) introduces a new binding using the GPIO library.
> 
> With this patch the mii bus is now identified by the GPIO lib I/O resource 
> number if available and falls back to the register address when the device 
> tree uses the legacy binding.
> 
> There should be no dependencies. When the OF GPIO support is not selected 
> linux/of_gpio.h will define of_get_gpio() as a stub, so the fs_enet driver 
> will fall back to the legacy binding.

Have we reached a consensus on which tree the patch should go to ?

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

Content of type "application/pgp-signature" skipped