1. 30 9月, 2008 1 次提交
  2. 25 4月, 2008 2 次提交
  3. 08 12月, 2007 1 次提交
  4. 18 10月, 2007 1 次提交
  5. 17 10月, 2007 1 次提交
  6. 16 10月, 2007 2 次提交
  7. 11 10月, 2007 2 次提交
    • R
      ibm_emac: Convert to use napi_struct independent of struct net_device · 59e90b2d
      Roland Dreier 提交于
      Commit da3dedd9 ("[NET]: Make NAPI polling independent of struct
      net_device objects.") changed the interface to NAPI polling.  Fix up
      the ibm_newemac driver so that it works with this new interface.  This
      is actually a nice cleanup because ibm_newemac is one of the drivers
      that wants to have multiple NAPI structures for a single net_device.
      
      Compile-tested only as I don't have a system that uses the ibm_newemac
      driver.  This conversion the conversion for the ibm_emac driver that
      was tested on real PowerPC 440SPe hardware.
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      59e90b2d
    • 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