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:	Wed, 18 Jun 2008 17:16:39 +0200
From:	Laurent Pinchart <laurentp@...-semaphore.com>
To:	Jeff Garzik <jgarzik@...ox.com>
Cc:	Scott Wood <scottwood@...escale.com>, linuxppc-dev@...abs.org,
	netdev@...r.kernel.org, vbordug@...mvista.com,
	pantelis.antoniou@...il.com
Subject: Re: [PATCH 2/2] fs_enet: MDIO on GPIO support

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.

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