Re: [PATCH 2/2] fs_enet: MDIO on GPIO support
On Thursday 26 June 2008, Vitaly Bordug wrote: On Thu, 26 Jun 2008 13:21:23 +0200 Laurent Pinchart [EMAIL PROTECTED] wrote: 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 ? I think it should go through powerpc tree, not seeing too much netdev-generic stuff in here. If noone will object, Kumar will pick it up I guess... Kumar, could you pick it up ? I'd like to see this in 2.6.27. Best regards, -- 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 signature.asc Description: This is a digitally signed message part. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] fs_enet: MDIO on GPIO support
On Jul 18, 2008, at 4:26 AM, Laurent Pinchart wrote: On Thursday 26 June 2008, Vitaly Bordug wrote: On Thu, 26 Jun 2008 13:21:23 +0200 Laurent Pinchart [EMAIL PROTECTED] wrote: 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 ? I think it should go through powerpc tree, not seeing too much netdev-generic stuff in here. If noone will object, Kumar will pick it up I guess... Kumar, could you pick it up ? I'd like to see this in 2.6.27. Best regards, Jeff said he applied both to his tree already. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] fs_enet: MDIO on GPIO support
Kumar Gala wrote: On Jul 18, 2008, at 4:26 AM, Laurent Pinchart wrote: On Thursday 26 June 2008, Vitaly Bordug wrote: On Thu, 26 Jun 2008 13:21:23 +0200 Laurent Pinchart [EMAIL PROTECTED] wrote: 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 ? I think it should go through powerpc tree, not seeing too much netdev-generic stuff in here. If noone will object, Kumar will pick it up I guess... Kumar, could you pick it up ? I'd like to see this in 2.6.27. Best regards, Jeff said he applied both to his tree already. Yep, it's already in davem's net-next... Jeff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
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 [EMAIL PROTECTED]
- 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
pgpLVrvJJ7FCw.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] fs_enet: MDIO on GPIO support
On Thu, 26 Jun 2008 13:21:23 +0200 Laurent Pinchart [EMAIL PROTECTED] wrote: 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 ? I think it should go through powerpc tree, not seeing too much netdev-generic stuff in here. If noone will object, Kumar will pick it up I guess... -- Sincerely, Vitaly ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] fs_enet: MDIO on GPIO support
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 [EMAIL PROTECTED]
- 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);
It'd be nice if this sort of thing could be moved to phylib, so the latter
could simply be passed a device node (in addition to current mechanisms for
the benefit of unfortunate device-tree-less architectures).
Adding a phy_connect_of that would move the above logic to phy_device.c
shouldn't be too difficult. Would that be enough ? The mdio bus code would
still use the bus id to identify phy devices in mdiobus_register.
--
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
pgpoXpSImGemR.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] fs_enet: MDIO on GPIO support
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 [EMAIL PROTECTED]
- 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.
Jeff
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
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 [EMAIL PROTECTED]
-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
pgpfpapob706J.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] fs_enet: MDIO on GPIO support
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 ?
Signed-off-by: Laurent Pinchart [EMAIL PROTECTED]
---
drivers/net/fs_enet/fs_enet-main.c | 31 ---
1 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_enet-main.c
index 67b4b07..b0eb1d2 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -43,6 +43,7 @@
#include asm/uaccess.h
#ifdef CONFIG_PPC_CPM_NEW_BINDING
+#include linux/of_gpio.h
#include asm/of_platform.h
#endif
@@ -1172,8 +1173,7 @@ static int __devinit find_phy(struct device_node *np,
struct fs_platform_info *fpi)
{
struct device_node *phynode, *mdionode;
- struct resource res;
- int ret = 0, len;
+ int ret = 0, len, bus_id;
const u32 *data;
data = of_get_property(np, fixed-link, NULL);
@@ -1190,19 +1190,28 @@ static int __devinit find_phy(struct device_node
*np,
if (!phynode)
return -EINVAL;
- mdionode = of_get_parent(phynode);
- if (!mdionode)
+ data = of_get_property(phynode, reg, len);
+ if (!data || len != 4) {
+ ret = -EINVAL;
goto out_put_phy;
+ }
- ret = of_address_to_resource(mdionode, 0, res);
- if (ret)
- goto out_put_mdio;
+ mdionode = of_get_parent(phynode);
+ if (!mdionode) {
+ ret = -EINVAL;
+ goto out_put_phy;
+ }
- 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);
out_put_mdio:
of_node_put(mdionode);
--
1.5.0
--
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
pgpUol02feTbo.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] fs_enet: MDIO on GPIO support
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...
Acked-by: Scott Wood [EMAIL PROTECTED]
- 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);
It'd be nice if this sort of thing could be moved to phylib, so the latter
could simply be passed a device node (in addition to current mechanisms for
the benefit of unfortunate device-tree-less architectures).
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
