1. 11 7月, 2008 9 次提交
  2. 07 7月, 2008 1 次提交
  3. 17 4月, 2008 1 次提交
  4. 26 3月, 2008 4 次提交
  5. 29 1月, 2008 1 次提交
  6. 21 1月, 2008 1 次提交
    • D
      [NET]: Fix interrupt semaphore corruption in Intel drivers. · 49d85c50
      David S. Miller 提交于
      Several of the Intel ethernet drivers keep an atomic counter used to
      manage when to actually hit the hardware with a disable or an enable.
      
      The way the net_rx_work() breakout logic works during a pending
      napi_disable() is that it simply unschedules the poll even if it
      still has work.
      
      This can potentially leave interrupts disabled, but that is OK
      because all of the drivers are about to disable interrupts
      anyways in all such code paths that do a napi_disable().
      
      Unfortunately, this trips up the semaphore used here in the Intel
      drivers.  If you hit this case, when you try to bring the interface
      back up it won't enable interrupts.  A reload of the driver module
      fixes it of course.
      
      So what we do is make sure all the sequences now go:
      
      	napi_disable();
      	atomic_set(&adapter->irq_sem, 0);
      	*_irq_disable();
      
      which makes sure the counter is always in the correct state.
      
      Reported by Robert Olsson.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      49d85c50
  7. 09 1月, 2008 2 次提交
  8. 15 12月, 2007 1 次提交
  9. 31 10月, 2007 2 次提交
  10. 11 10月, 2007 2 次提交
    • R
      [NET]: Nuke SET_MODULE_OWNER macro. · 10d024c1
      Ralf Baechle 提交于
      It's been a useless no-op for long enough in 2.6 so I figured it's time to
      remove it.  The number of people that could object because they're
      maintaining unified 2.4 and 2.6 drivers is probably rather small.
      
      [ Handled drivers added by netdev tree and some missed IRDA cases... -DaveM ]
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      10d024c1
    • S
      [NET]: Make NAPI polling independent of struct net_device objects. · bea3348e
      Stephen Hemminger 提交于
      Several devices have multiple independant RX queues per net
      device, and some have a single interrupt doorbell for several
      queues.
      
      In either case, it's easier to support layouts like that if the
      structure representing the poll is independant from the net
      device itself.
      
      The signature of the ->poll() call back goes from:
      
      	int foo_poll(struct net_device *dev, int *budget)
      
      to
      
      	int foo_poll(struct napi_struct *napi, int budget)
      
      The caller is returned the number of RX packets processed (or
      the number of "NAPI credits" consumed if you want to get
      abstract).  The callee no longer messes around bumping
      dev->quota, *budget, etc. because that is all handled in the
      caller upon return.
      
      The napi_struct is to be embedded in the device driver private data
      structures.
      
      Furthermore, it is the driver's responsibility to disable all NAPI
      instances in it's ->stop() device close handler.  Since the
      napi_struct is privatized into the driver's private data structures,
      only the driver knows how to get at all of the napi_struct instances
      it may have per-device.
      
      With lots of help and suggestions from Rusty Russell, Roland Dreier,
      Michael Chan, Jeff Garzik, and Jamal Hadi Salim.
      
      Bug fixes from Thomas Graf, Roland Dreier, Peter Zijlstra,
      Joseph Fannin, Scott Wood, Hans J. Koch, and Michael Chan.
      
      [ Ported to current tree and all drivers converted.  Integrated
        Stephen's follow-on kerneldoc additions, and restored poll_list
        handling to the old style to fix mutual exclusion issues.  -DaveM ]
      Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bea3348e
  11. 18 5月, 2007 1 次提交
  12. 28 4月, 2007 1 次提交
  13. 26 4月, 2007 6 次提交
  14. 03 3月, 2007 1 次提交
  15. 08 2月, 2007 1 次提交
  16. 06 2月, 2007 1 次提交
  17. 07 1月, 2007 3 次提交
  18. 03 12月, 2006 1 次提交
  19. 22 11月, 2006 1 次提交