1. 18 6月, 2009 1 次提交
  2. 13 6月, 2009 2 次提交
  3. 11 6月, 2009 1 次提交
    • A
      e100: add non-MII PHY support · 72001762
      Andreas Mohr 提交于
      Restore support for cards with MII-lacking PHYs as compared to removed
      pre-2.6.29 eepro100 driver: use full low-level MII I/O access abstraction
      by providing clean PHY-specific mdio_ctrl() functions for either standard
      MII-compliant cards, slightly special ones or non-MII PHY ones.
      
      We now have another netdev_priv member for mdio_ctrl(), thus we have some
      array indirection, but we save some additional opcodes for specific
      phy_82552_v handling in the common case.
      
      [akpm@linux-foundation.org: cleanups]
      Signed-off-by: NAndreas Mohr <andi@lisas.de>
      Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
      Cc: Bruce Allan <bruce.w.allan@intel.com>
      Cc: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
      Cc: John Ronciak <john.ronciak@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      72001762
  4. 08 6月, 2009 1 次提交
  5. 29 4月, 2009 1 次提交
  6. 07 4月, 2009 1 次提交
  7. 22 3月, 2009 1 次提交
  8. 22 1月, 2009 1 次提交
  9. 08 1月, 2009 1 次提交
  10. 05 1月, 2009 1 次提交
  11. 23 12月, 2008 1 次提交
  12. 27 11月, 2008 1 次提交
  13. 21 11月, 2008 1 次提交
  14. 20 11月, 2008 1 次提交
  15. 16 11月, 2008 1 次提交
  16. 04 11月, 2008 1 次提交
  17. 31 10月, 2008 1 次提交
  18. 28 10月, 2008 1 次提交
  19. 25 9月, 2008 1 次提交
  20. 19 9月, 2008 1 次提交
  21. 27 8月, 2008 1 次提交
    • J
      e100, fix iomap read · 17393dd6
      Jiri Slaby 提交于
      There were 2 omitted readb's used on an iomap space. eliminate them
      by using ioread8 instead.
      Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
      Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
      Cc: Bruce Allan <bruce.w.allan@intel.com>
      Cc: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
      Cc: John Ronciak <john.ronciak@intel.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      17393dd6
  22. 27 7月, 2008 1 次提交
    • F
      dma-mapping: add the device argument to dma_mapping_error() · 8d8bb39b
      FUJITA Tomonori 提交于
      Add per-device dma_mapping_ops support for CONFIG_X86_64 as POWER
      architecture does:
      
      This enables us to cleanly fix the Calgary IOMMU issue that some devices
      are not behind the IOMMU (http://lkml.org/lkml/2008/5/8/423).
      
      I think that per-device dma_mapping_ops support would be also helpful for
      KVM people to support PCI passthrough but Andi thinks that this makes it
      difficult to support the PCI passthrough (see the above thread).  So I
      CC'ed this to KVM camp.  Comments are appreciated.
      
      A pointer to dma_mapping_ops to struct dev_archdata is added.  If the
      pointer is non NULL, DMA operations in asm/dma-mapping.h use it.  If it's
      NULL, the system-wide dma_ops pointer is used as before.
      
      If it's useful for KVM people, I plan to implement a mechanism to register
      a hook called when a new pci (or dma capable) device is created (it works
      with hot plugging).  It enables IOMMUs to set up an appropriate
      dma_mapping_ops per device.
      
      The major obstacle is that dma_mapping_error doesn't take a pointer to the
      device unlike other DMA operations.  So x86 can't have dma_mapping_ops per
      device.  Note all the POWER IOMMUs use the same dma_mapping_error function
      so this is not a problem for POWER but x86 IOMMUs use different
      dma_mapping_error functions.
      
      The first patch adds the device argument to dma_mapping_error.  The patch
      is trivial but large since it touches lots of drivers and dma-mapping.h in
      all the architecture.
      
      This patch:
      
      dma_mapping_error() doesn't take a pointer to the device unlike other DMA
      operations.  So we can't have dma_mapping_ops per device.
      
      Note that POWER already has dma_mapping_ops per device but all the POWER
      IOMMUs use the same dma_mapping_error function.  x86 IOMMUs use device
      argument.
      
      [akpm@linux-foundation.org: fix sge]
      [akpm@linux-foundation.org: fix svc_rdma]
      [akpm@linux-foundation.org: build fix]
      [akpm@linux-foundation.org: fix bnx2x]
      [akpm@linux-foundation.org: fix s2io]
      [akpm@linux-foundation.org: fix pasemi_mac]
      [akpm@linux-foundation.org: fix sdhci]
      [akpm@linux-foundation.org: build fix]
      [akpm@linux-foundation.org: fix sparc]
      [akpm@linux-foundation.org: fix ibmvscsi]
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Muli Ben-Yehuda <muli@il.ibm.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Avi Kivity <avi@qumranet.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8d8bb39b
  23. 27 6月, 2008 1 次提交
  24. 29 4月, 2008 1 次提交
  25. 26 3月, 2008 1 次提交
  26. 05 3月, 2008 1 次提交
  27. 03 2月, 2008 2 次提交
  28. 29 1月, 2008 3 次提交
    • A
      e100 endianness annotations · aaf918ba
      Al Viro 提交于
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      aaf918ba
    • D
      Fix e100 on systems that have cache incoherent DMA · 7734f6e6
      David Acker 提交于
      On the systems that have cache incoherent DMA, including ARM, there
      is a race condition between software allocating a new receive buffer
      and hardware writing into a buffer.  The two race on touching the last
      Receive Frame Descriptor (RFD).  It has its el-bit set and its next
      link equal to 0.  When hardware encounters this buffer it attempts to
      write data to it and then update Status Word bits and Actual Count in
      the RFD.  At the same time software may try to clear the el-bit and
      set the link address to a new buffer.
      
      Since the entire RFD is once cache-line, the two write operations can
      collide.  This can lead to the receive unit stalling or interpreting
      random memory as its receive area.
      
      The fix is to set the el-bit on and the size to 0 on the next to last
      buffer in the chain.  When the hardware encounters this buffer it stops
      and does not write to it at all.  The hardware issues an RNR interrupt
      with the receive unit in the No Resources state.  Software can write
      to the tail of the list because it knows hardware will stop on the
      previous descriptor that was marked as the end of list.
      
      Once it has a new next to last buffer prepared, it can clear the el-bit
      and set the size on the previous one.  The race on this buffer is safe
      since the link already points to a valid next buffer and the software
      can handle the race setting the size (assuming aligned 16 bit writes
      are atomic with respect to the DMA read). If the hardware sees the
      el-bit cleared without the size set, it will move on to the next buffer
      and skip this one.  If it sees the size set but the el-bit still set,
      it will complete that buffer and then RNR interrupt and wait.
      Signed-off-by: NDavid Acker <dacker@roinet.com>
      Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      7734f6e6
    • A
      netdev: use ARRAY_SIZE() instead of sizeof(array) / ETH_GSTRING_LEN · 4c3616cd
      Alejandro Martinez Ruiz 提交于
      Using ARRAY_SIZE() on arrays of the form array[][K] makes it unnecessary
      to know the value of K when checking its size.
      Signed-off-by: NAlejandro Martinez Ruiz <alex@flawedcode.org>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      4c3616cd
  29. 09 1月, 2008 2 次提交
  30. 15 12月, 2007 1 次提交
  31. 08 12月, 2007 1 次提交
  32. 20 10月, 2007 1 次提交
  33. 11 10月, 2007 3 次提交