1. 18 Dec, 2008 1 commit
    • Jesper Dangaard Brouer's avatar
      NIU: Implement discard counters · b8a606b8
      Jesper Dangaard Brouer authored
      Implementing discard counters for the NIU driver turned out to be more
      complicated than first assumed.
      
      The discard counters for the NIU neptune chip are only 16-bit (even
      though this is a 64-bit chip).  These 16-bit counters can overflow
      quickly, especially considering this is a 10Gbit/s ethernet card.
      
      The overflow indication bit is, unfortunatly, not usable as the
      counter value does not wrap, but remains at max value 0xFFFF.
      Resulting in lost counts until the counter is reset.
      
      The read and reset scheme also poses a problem. Both in theory and in
      practice counters can be lost in between reading nr64() and clearing
      the counter nw64().  For this reason, the number of counter clearings
      nw64() is limited/reduced.  On the fast-path the counters are only
      syncronized once it exceeds 0x7FFF.  When read by userspace, its
      syncronized fully.
      Signed-off-by: default avatarJesper Dangaard Brouer <hawk@comx.dk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b8a606b8
  2. 28 Nov, 2008 1 commit
  3. 25 Nov, 2008 3 commits
  4. 20 Nov, 2008 1 commit
  5. 19 Nov, 2008 1 commit
  6. 14 Nov, 2008 2 commits
  7. 12 Nov, 2008 1 commit
    • David S. Miller's avatar
      niu: Fix readq implementation when architecture does not provide one. · e23a59e1
      David S. Miller authored
      This fixes a TX hang reported by Jesper Dangaard Brouer.
      
      When an architecutre cannot provide a fully functional
      64-bit atomic readq/writeq, the driver must implement
      it's own.  This is because only the driver can say whether
      doing something like using two 32-bit reads to implement
      the full 64-bit read will actually work properly.
      
      In particular one of the issues is whether the top 32-bits
      or the bottom 32-bits of the 64-bit register should be read
      first.  There could be side effects, and in fact that is
      exactly the problem here.
      
      The TX_CS register has counters in the upper 32-bits and
      state bits in the lower 32-bits.  A read clears the state
      bits.
      
      We would read the counter half before the state bit half.
      That first read would clear the state bits, and then the
      driver thinks that no interrupts are pending because the
      interrupt indication state bits are seen clear every time.
      
      Fix this by reading the bottom half before the upper half.
      Tested-by: default avatarJesper Dangaard Brouer <jdb@comx.dk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e23a59e1
  8. 03 Nov, 2008 2 commits
  9. 27 Oct, 2008 1 commit
  10. 12 Sep, 2008 1 commit
  11. 31 Aug, 2008 1 commit
  12. 30 Jul, 2008 1 commit
  13. 17 Jul, 2008 1 commit
  14. 02 Jul, 2008 1 commit
  15. 12 May, 2008 1 commit
  16. 04 May, 2008 1 commit
  17. 24 Apr, 2008 2 commits
  18. 28 Feb, 2008 1 commit
  19. 20 Feb, 2008 1 commit
  20. 18 Feb, 2008 2 commits
  21. 28 Jan, 2008 1 commit
  22. 17 Jan, 2008 1 commit
  23. 10 Jan, 2008 1 commit
    • Mirko Lindner's avatar
      [NIU]: Support for Marvell PHY · b0de8e40
      Mirko Lindner authored
      From: Mirko Lindner <mlindner@marvell.com>
      
      This patch makes necessary changes in the Neptune driver to support 
      the new Marvell PHY. It also adds support for the LED blinking
      on Neptune cards with Marvell PHY. All registers are using defines
      in the niu.h header file as is already done for the BCM8704 registers.
      
      [ Coding style, etc. cleanups -DaveM ]
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b0de8e40
  24. 09 Jan, 2008 4 commits
    • David S. Miller's avatar
      cb77df3e
    • David S. Miller's avatar
      [NIU]: Fix potentially stuck TCP socket send queues. · 3ebebccf
      David S. Miller authored
      It is possible for the TX ring to have packets sit in it for unbounded
      amounts of time.
      
      The only way to defer TX interrupts in the chip is to periodically set
      "mark" bits, when processing of a TX descriptor with the mark bit set
      is complete it triggers the interrupt for the TX queue's LDG.
      
      A consequence of this kind of scheme is that if packet flow suddenly
      stops, the remaining TX packets will just sit there.
      
      If this happens, since those packets could be charged to TCP socket
      send queues, such sockets could get stuck.
      
      The simplest solution is to divorce the socket ownership of the packet
      once the device takes the SKB, by using skb_orphan() in
      niu_start_xmit().
      
      In hindsight, it would have been much nicer if the chip provided two
      interrupt sources for TX (like basically every other ethernet chip
      does).  Namely, keep the "mark" bit, but also signal the LDG when the
      TX queue becomes completely empty.  That way there is no need to have
      a deadlock breaker like this.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3ebebccf
    • David S. Miller's avatar
      [NIU]: Missing ->last_rx update. · 792dd90f
      David S. Miller authored
      Noticed by Paul Lodridge.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      792dd90f
    • Matheos Worku's avatar
      [NIU]: Fix slowpath interrupt handling. · 406f353c
      Matheos Worku authored
      niu_slowpath_interrupt() expects values to be setup in lp->{v0,v1,v2}
      but they aren't.  That's only done by niu_schedule_napi() which is
      done later in the interrupt path.
      
      If niu_rx_error() returns zero, and v0 is clear, hit the
      RX_DMA_CTL_STATE register with a RX_DMA_CTL_STAT_MEX.
      
      Only emit verbose RX error logs if a fatal channel or port error is
      signalled.  Other cases will be recorded into statistics by
      niu_log_rxchan_errors().
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      406f353c
  25. 07 Dec, 2007 1 commit
  26. 22 Oct, 2007 1 commit
    • Olof Johansson's avatar
      [NIU]: Cleanup PAGE_SIZE checks a bit · 81429973
      Olof Johansson authored
      I get the following warning from a powerpc allyesconfig of current
      mainline:
      
      drivers/net/niu.c: In function 'niu_size_rbr':
      drivers/net/niu.c:3113: warning: large integer implicitly truncated to unsigned type
      
      PAGE_SIZE in this case is 64KB, so I don't quite get why gcc can't
      tell that the line in question will never be reached.
      
      I suggest the following instead, but I can unfortunately not do
      anything but build test it.
      
      Also, the driver does some other checks to make sure that PAGE_SIZE is
      a power of two (BUILD_BUG_ON() in niu_init()), doesn't seem like that
      could ever be untrue? Or are there really archs with non-power-of-two
      PAGE_SIZE?
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      81429973
  27. 15 Oct, 2007 2 commits
  28. 10 Oct, 2007 1 commit