1. 11 8月, 2011 1 次提交
    • J
      ehea/ibm*: Move the IBM drivers · 9aa32835
      Jeff Kirsher 提交于
      Move the IBM drivers into drivers/net/ethernet/ibm/ and make the
      necessary Kconfig and Makefile changes.
      
      - Renamed ibm_new_emac to emac
      - Cleaned up Makefile and Kconfig options which referred to
        IBM_NEW_EMAC to IBM_EMAC
      - ibmlana driver is a National Semiconductor SONIC driver so
        it was not moved
      
      CC: Christoph Raisch <raisch@de.ibm.com>
      CC: Santiago Leon <santil@linux.vnet.ibm.com>
      CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      CC: David Gibson <dwg@au1.ibm.com>
      CC: Kyle Lucke <klucke@us.ibm.com>
      CC: Michael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      9aa32835
  2. 11 10月, 2007 1 次提交
    • D
      Device tree aware EMAC driver · 1d3bb996
      David Gibson 提交于
      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 (that 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: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      1d3bb996