* Device tree aware EMAC driver
@ 2007-05-30 6:17 David Gibson
0 siblings, 0 replies; 13+ messages in thread
From: David Gibson @ 2007-05-30 6:17 UTC (permalink / raw)
To: linuxppc-dev
This is BenH's rewritten, device tree aware driver for the IBM/AMCC
EMAC, ethernet MAC controller ASIC found on various 4xx CPUs and also
the Axon bridge.
- Updated to build on current kernels
- Removed device_type matching requirement on MAL and ZMII, to
match current best practice of omitting device_type unless a
well-defined class binding exists.
- Added documentation to booting-without-of.txt for the EMAC
binding.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Download from:
http://ozlabs.org/~dgibson/home/emac/powerpc-emac-new-20070530.patch
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply [flat|nested] 13+ messages in thread
* Device tree aware EMAC driver
@ 2007-08-07 6:22 David Gibson
2007-08-07 12:15 ` Josh Boyer
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: David Gibson @ 2007-08-07 6:22 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt, Josh Boyer, Jon Loeliger,
linuxppc-dev
Based on BenH's earlier work, this is a new version of the EMAC driver
for the built-in ethernet found on PowerPC 4xx embedded CPUs. The
same ASIC is also found in the Axon bridge chip. This new version is
designed to work in the arch/powerpc tree, using the device tree to
probe the device, rather than the old and ugly arch/ppc OCP layer.
This driver is designed to sit alongside the old driver (it lies in
drivers/net/ibm_emac and this one in drivers/net/ibm_newemac). The
old driver is left in place to support arch/ppc until arch/ppc itself
reaches its final demise (not too long now, with luck).
This driver still has a number of things that could do with cleaning
up, but I think they can be fixed up after merging. Specifically:
- Should be adjusted to properly use the dma mapping API.
Axon needs this.
- Probe logic needs reworking, in conjuction with the general
probing code for of_platform devices. The dependencies here between
EMAC, MAL, ZMII etc. make this complicated. At present, it usually
works, because we initialize and register the sub-drivers before the
EMAC driver itself, and (being in driver code) runs after the devices
themselves have been instantiated from the device tree.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
Paul, I discussed with BenH, and although there are some problems with
the driver still, we think it's good enough to merge in 2.6.24, the
warts can be fixed up later.
Too big for the list, patch is at:
http://ozlabs.org/~dgibson/home/emac/powerpc-emac-new-20070807.patch
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Device tree aware EMAC driver
2007-08-07 6:22 David Gibson
@ 2007-08-07 12:15 ` Josh Boyer
2007-08-08 1:18 ` David Gibson
2007-08-08 3:16 ` Tony Breeds
2007-08-11 3:51 ` Olof Johansson
2 siblings, 1 reply; 13+ messages in thread
From: Josh Boyer @ 2007-08-07 12:15 UTC (permalink / raw)
To: David Gibson; +Cc: Paul Mackerras, linuxppc-dev
On Tue, 7 Aug 2007 16:22:31 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> Based on BenH's earlier work, this is a new version of the EMAC driver
> for the built-in ethernet found on PowerPC 4xx embedded CPUs. The
> same ASIC is also found in the Axon bridge chip. This new version is
> designed to work in the arch/powerpc tree, using the device tree to
> probe the device, rather than the old and ugly arch/ppc OCP layer.
>
> This driver is designed to sit alongside the old driver (it lies in
> drivers/net/ibm_emac and this one in drivers/net/ibm_newemac). The
> old driver is left in place to support arch/ppc until arch/ppc itself
> reaches its final demise (not too long now, with luck).
>
> This driver still has a number of things that could do with cleaning
> up, but I think they can be fixed up after merging. Specifically:
> - Should be adjusted to properly use the dma mapping API.
> Axon needs this.
> - Probe logic needs reworking, in conjuction with the general
> probing code for of_platform devices. The dependencies here between
> EMAC, MAL, ZMII etc. make this complicated. At present, it usually
> works, because we initialize and register the sub-drivers before the
> EMAC driver itself, and (being in driver code) runs after the devices
> themselves have been instantiated from the device tree.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Hm. Should this go through Jeff Garzik or Paul? If it's the latter,
I'll pull this into my git tree soon.
josh
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Device tree aware EMAC driver
2007-08-07 12:15 ` Josh Boyer
@ 2007-08-08 1:18 ` David Gibson
0 siblings, 0 replies; 13+ messages in thread
From: David Gibson @ 2007-08-08 1:18 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Paul Mackerras
On Tue, Aug 07, 2007 at 07:15:39AM -0500, Josh Boyer wrote:
> On Tue, 7 Aug 2007 16:22:31 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
>
> > Based on BenH's earlier work, this is a new version of the EMAC driver
> > for the built-in ethernet found on PowerPC 4xx embedded CPUs. The
> > same ASIC is also found in the Axon bridge chip. This new version is
> > designed to work in the arch/powerpc tree, using the device tree to
> > probe the device, rather than the old and ugly arch/ppc OCP layer.
> >
> > This driver is designed to sit alongside the old driver (it lies in
> > drivers/net/ibm_emac and this one in drivers/net/ibm_newemac). The
> > old driver is left in place to support arch/ppc until arch/ppc itself
> > reaches its final demise (not too long now, with luck).
> >
> > This driver still has a number of things that could do with cleaning
> > up, but I think they can be fixed up after merging. Specifically:
> > - Should be adjusted to properly use the dma mapping API.
> > Axon needs this.
> > - Probe logic needs reworking, in conjuction with the general
> > probing code for of_platform devices. The dependencies here between
> > EMAC, MAL, ZMII etc. make this complicated. At present, it usually
> > works, because we initialize and register the sub-drivers before the
> > EMAC driver itself, and (being in driver code) runs after the devices
> > themselves have been instantiated from the device tree.
> >
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>
> Hm. Should this go through Jeff Garzik or Paul? If it's the latter,
> I'll pull this into my git tree soon.
Through Jeff Garzik, I think. I was planning to send it to him today
or tomorrow if there are no screams from the linuxppc-dev list.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Device tree aware EMAC driver
2007-08-07 6:22 David Gibson
2007-08-07 12:15 ` Josh Boyer
@ 2007-08-08 3:16 ` Tony Breeds
2007-08-08 5:09 ` David Gibson
` (2 more replies)
2007-08-11 3:51 ` Olof Johansson
2 siblings, 3 replies; 13+ messages in thread
From: Tony Breeds @ 2007-08-08 3:16 UTC (permalink / raw)
To: LinuxPPC-dev, David Gibson
On Tue, Aug 07, 2007 at 04:22:31PM +1000, David Gibson wrote:
> Based on BenH's earlier work, this is a new version of the EMAC driver
> for the built-in ethernet found on PowerPC 4xx embedded CPUs. The
> same ASIC is also found in the Axon bridge chip. This new version is
> designed to work in the arch/powerpc tree, using the device tree to
> probe the device, rather than the old and ugly arch/ppc OCP layer.
<snip>
Hi David,
I had a look over the patch FWIW, asside from the points below
looks good.
Minor nits:
* Shouldn't ndev->priv accesses, use netdev_priv() ? if not a comment
somewhere about why not will keep the janators off your back.
* c++ style comments
* in emac_probe():
+ /* Wait for dependent devices */
+ err = -ENODEV;
+ err = emac_wait_deps(dev);
The initialisation to -ENODEV is pointless right?
* s/get_property/of_get_property/g or you'll make sfr grumpy ;P
* In drivers/net/ibm_newemac/Makefile, I think the preferred method is
to use ibm_newemac-y rather than ibm_newemac-objs.
Is there any reason to leave config IBM_NEW_EMAC (and IBM_EMAC) in
drivers/net/Kconfig ? It seems to me they'd be nicer to in the
appropriate drivers/net/*Kconfig.
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Device tree aware EMAC driver
2007-08-08 3:16 ` Tony Breeds
@ 2007-08-08 5:09 ` David Gibson
2007-08-08 7:34 ` Benjamin Herrenschmidt
2007-08-08 7:33 ` Benjamin Herrenschmidt
2007-08-10 20:39 ` Segher Boessenkool
2 siblings, 1 reply; 13+ messages in thread
From: David Gibson @ 2007-08-08 5:09 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev
On Wed, Aug 08, 2007 at 01:16:43PM +1000, Tony Breeds wrote:
> On Tue, Aug 07, 2007 at 04:22:31PM +1000, David Gibson wrote:
> > Based on BenH's earlier work, this is a new version of the EMAC driver
> > for the built-in ethernet found on PowerPC 4xx embedded CPUs. The
> > same ASIC is also found in the Axon bridge chip. This new version is
> > designed to work in the arch/powerpc tree, using the device tree to
> > probe the device, rather than the old and ugly arch/ppc OCP layer.
>
> <snip>
>
> Hi David,
> I had a look over the patch FWIW, asside from the points below
> looks good.
>
> Minor nits:
> * Shouldn't ndev->priv accesses, use netdev_priv() ? if not a comment
> somewhere about why not will keep the janators off your back.
netdev_priv() hey? Hadn't heard of that before. I guess
so... Changed.
> * c++ style comments
Eh, all the c++ comments are FIXMEs anyway. I'm inclined to leave
them.
> * in emac_probe():
> + /* Wait for dependent devices */
> + err = -ENODEV;
> + err = emac_wait_deps(dev);
> The initialisation to -ENODEV is pointless right?
Yes, I think so. Removed.
> * s/get_property/of_get_property/g or you'll make sfr grumpy ;P
Oops, yes.
> * In drivers/net/ibm_newemac/Makefile, I think the preferred method is
> to use ibm_newemac-y rather than ibm_newemac-objs.
>
> Is there any reason to leave config IBM_NEW_EMAC (and IBM_EMAC) in
> drivers/net/Kconfig ? It seems to me they'd be nicer to in the
> appropriate drivers/net/*Kconfig.
Yes, and that also seems to be how it's done for tulip. Moved.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Device tree aware EMAC driver
2007-08-08 3:16 ` Tony Breeds
2007-08-08 5:09 ` David Gibson
@ 2007-08-08 7:33 ` Benjamin Herrenschmidt
2007-08-10 20:39 ` Segher Boessenkool
2 siblings, 0 replies; 13+ messages in thread
From: Benjamin Herrenschmidt @ 2007-08-08 7:33 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev, David Gibson
> * c++ style comments
Ouch... I haven't removed them all ? I promise I didn't -add- any :-)
> * in emac_probe():
> + /* Wait for dependent devices */
> + err = -ENODEV;
> + err = emac_wait_deps(dev);
> The initialisation to -ENODEV is pointless right?
Leftover from when it was coded differently yes.
> * s/get_property/of_get_property/g or you'll make sfr grumpy ;)
> * In drivers/net/ibm_newemac/Makefile, I think the preferred method is
> to use ibm_newemac-y rather than ibm_newemac-objs.
>
> Is there any reason to leave config IBM_NEW_EMAC (and IBM_EMAC) in
> drivers/net/Kconfig ? It seems to me they'd be nicer to in the
> appropriate drivers/net/*Kconfig.
Probably.
Ben.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Device tree aware EMAC driver
2007-08-08 5:09 ` David Gibson
@ 2007-08-08 7:34 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 13+ messages in thread
From: Benjamin Herrenschmidt @ 2007-08-08 7:34 UTC (permalink / raw)
To: David Gibson; +Cc: LinuxPPC-dev
On Wed, 2007-08-08 at 15:09 +1000, David Gibson wrote:
>
> Eh, all the c++ comments are FIXMEs anyway. I'm inclined to leave
> them.
Ahah... maybe I -did- add some of those then :-) I do use C++ comments
for FIXME's on purpose, because they are ugly, it improves the changes
that I actually get to fix whatever needs fixing :-)
Ben.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Device tree aware EMAC driver
2007-08-08 3:16 ` Tony Breeds
2007-08-08 5:09 ` David Gibson
2007-08-08 7:33 ` Benjamin Herrenschmidt
@ 2007-08-10 20:39 ` Segher Boessenkool
2007-08-13 1:05 ` David Gibson
2 siblings, 1 reply; 13+ messages in thread
From: Segher Boessenkool @ 2007-08-10 20:39 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev, David Gibson
> * In drivers/net/ibm_newemac/Makefile, I think the preferred method is
> to use ibm_newemac-y rather than ibm_newemac-objs.
I thought it was the other way around, so I checked with the
Kbuild maintainer, and indeed you are correct.
Segher
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Device tree aware EMAC driver
2007-08-07 6:22 David Gibson
2007-08-07 12:15 ` Josh Boyer
2007-08-08 3:16 ` Tony Breeds
@ 2007-08-11 3:51 ` Olof Johansson
2 siblings, 0 replies; 13+ messages in thread
From: Olof Johansson @ 2007-08-11 3:51 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt, Josh Boyer, Jon Loeliger,
linuxppc-dev
On Tue, Aug 07, 2007 at 04:22:31PM +1000, David Gibson wrote:
> This driver is designed to sit alongside the old driver (it lies in
> drivers/net/ibm_emac and this one in drivers/net/ibm_newemac). The
> old driver is left in place to support arch/ppc until arch/ppc itself
> reaches its final demise (not too long now, with luck).
I would very much prefer if the patch was provided as first a pure copy
without changes, then the actual diffs on top of that. The way it is now
is just a huge blob that's harder to review than it would otherwise be.
-Olof
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Device tree aware EMAC driver
2007-08-10 20:39 ` Segher Boessenkool
@ 2007-08-13 1:05 ` David Gibson
0 siblings, 0 replies; 13+ messages in thread
From: David Gibson @ 2007-08-13 1:05 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: LinuxPPC-dev
On Fri, Aug 10, 2007 at 10:39:31PM +0200, Segher Boessenkool wrote:
> > * In drivers/net/ibm_newemac/Makefile, I think the preferred method is
> > to use ibm_newemac-y rather than ibm_newemac-objs.
>
> I thought it was the other way around, so I checked with the
> Kbuild maintainer, and indeed you are correct.
Changed accordingly.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Device tree aware EMAC driver
[not found] <20070823035601.GL7042@localhost.localdomain>
@ 2007-08-23 7:30 ` Benjamin Herrenschmidt
2007-09-14 22:37 ` Josh Boyer
0 siblings, 1 reply; 13+ messages in thread
From: Benjamin Herrenschmidt @ 2007-08-23 7:30 UTC (permalink / raw)
To: David Gibson; +Cc: netdev, Jeff Garzik, Paul Mackerras, linuxppc-dev
On Thu, 2007-08-23 at 13:56 +1000, David Gibson wrote:
>
>
> Jeff, I've discussed this with BenH, and although there are some
> problems with the driver still, we think it's good enough to merge in
> 2.6.24, the warts can be fixed up later. Please apply...
Or to be more precise:
This driver will work well for 4xx platforms and will allow us to move a
big step toward getting rid of arch/ppc. The issues with DMA mapping
really only concern the case where this is used within the cell "Axon"
southbridge, which doesn't happen on any released product at this stage.
Ben.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Device tree aware EMAC driver
2007-08-23 7:30 ` Device tree aware EMAC driver Benjamin Herrenschmidt
@ 2007-09-14 22:37 ` Josh Boyer
0 siblings, 0 replies; 13+ messages in thread
From: Josh Boyer @ 2007-09-14 22:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, netdev, Jeff Garzik, Paul Mackerras, David Gibson
On Thu, 2007-08-23 at 09:30 +0200, Benjamin Herrenschmidt wrote:
> On Thu, 2007-08-23 at 13:56 +1000, David Gibson wrote:
> >
> >
> > Jeff, I've discussed this with BenH, and although there are some
> > problems with the driver still, we think it's good enough to merge in
> > 2.6.24, the warts can be fixed up later. Please apply...
>
> Or to be more precise:
>
> This driver will work well for 4xx platforms and will allow us to move a
> big step toward getting rid of arch/ppc. The issues with DMA mapping
> really only concern the case where this is used within the cell "Axon"
> southbridge, which doesn't happen on any released product at this stage.
Since we have 4 boards that could use this now, and at least one more on
the way, I've put this in the 'emac' branch of my git tree. That branch
is based off of the current 'upstream' branch of the netdev-2.6 tree.
This is just intended to make it easier for those that want to use
ibm_newemac on their boards while we work the driver into the netdev
tree.
josh
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2007-09-14 23:41 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20070823035601.GL7042@localhost.localdomain>
2007-08-23 7:30 ` Device tree aware EMAC driver Benjamin Herrenschmidt
2007-09-14 22:37 ` Josh Boyer
2007-08-07 6:22 David Gibson
2007-08-07 12:15 ` Josh Boyer
2007-08-08 1:18 ` David Gibson
2007-08-08 3:16 ` Tony Breeds
2007-08-08 5:09 ` David Gibson
2007-08-08 7:34 ` Benjamin Herrenschmidt
2007-08-08 7:33 ` Benjamin Herrenschmidt
2007-08-10 20:39 ` Segher Boessenkool
2007-08-13 1:05 ` David Gibson
2007-08-11 3:51 ` Olof Johansson
-- strict thread matches above, loose matches on Subject: below --
2007-05-30 6:17 David Gibson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).