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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ