1. 04 7月, 2006 1 次提交
  2. 03 7月, 2006 1 次提交
  3. 23 6月, 2006 2 次提交
    • H
      [NET]: Merge TSO/UFO fields in sk_buff · 7967168c
      Herbert Xu 提交于
      Having separate fields in sk_buff for TSO/UFO (tso_size/ufo_size) is not
      going to scale if we add any more segmentation methods (e.g., DCCP).  So
      let's merge them.
      
      They were used to tell the protocol of a packet.  This function has been
      subsumed by the new gso_type field.  This is essentially a set of netdev
      feature bits (shifted by 16 bits) that are required to process a specific
      skb.  As such it's easy to tell whether a given device can process a GSO
      skb: you just have to and the gso_type field and the netdev's features
      field.
      
      I've made gso_type a conjunction.  The idea is that you have a base type
      (e.g., SKB_GSO_TCPV4) that can be modified further to support new features.
      For example, if we add a hardware TSO type that supports ECN, they would
      declare NETIF_F_TSO | NETIF_F_TSO_ECN.  All TSO packets with CWR set would
      have a gso_type of SKB_GSO_TCPV4 | SKB_GSO_TCPV4_ECN while all other TSO
      packets would be SKB_GSO_TCPV4.  This means that only the CWR packets need
      to be emulated in software.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7967168c
    • A
      [PATCH] make drivers/net/forcedeth.c:nv_update_pause() static · c7985051
      Adrian Bunk 提交于
      This patch makes the needlessly global nv_update_pause() static.
      Signed-off-by: NAdrian Bunk <bunk@stusta.de>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      c7985051
  4. 21 6月, 2006 1 次提交
  5. 18 6月, 2006 1 次提交
    • H
      [NET]: Add netif_tx_lock · 932ff279
      Herbert Xu 提交于
      Various drivers use xmit_lock internally to synchronise with their
      transmission routines.  They do so without setting xmit_lock_owner.
      This is fine as long as netpoll is not in use.
      
      With netpoll it is possible for deadlocks to occur if xmit_lock_owner
      isn't set.  This is because if a printk occurs while xmit_lock is held
      and xmit_lock_owner is not set can cause netpoll to attempt to take
      xmit_lock recursively.
      
      While it is possible to resolve this by getting netpoll to use
      trylock, it is suboptimal because netpoll's sole objective is to
      maximise the chance of getting the printk out on the wire.  So
      delaying or dropping the message is to be avoided as much as possible.
      
      So the only alternative is to always set xmit_lock_owner.  The
      following patch does this by introducing the netif_tx_lock family of
      functions that take care of setting/unsetting xmit_lock_owner.
      
      I renamed xmit_lock to _xmit_lock to indicate that it should not be
      used directly.  I didn't provide irq versions of the netif_tx_lock
      functions since xmit_lock is meant to be a BH-disabling lock.
      
      This is pretty much a straight text substitution except for a small
      bug fix in winbond.  It currently uses
      netif_stop_queue/spin_unlock_wait to stop transmission.  This is
      unsafe as an IRQ can potentially wake up the queue.  So it is safer to
      use netif_tx_disable.
      
      The hamradio bits used spin_lock_irq but it is unnecessary as
      xmit_lock must never be taken in an IRQ handler.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      932ff279
  6. 11 6月, 2006 12 次提交
  7. 06 6月, 2006 1 次提交
  8. 27 5月, 2006 2 次提交
  9. 22 5月, 2006 1 次提交
  10. 20 5月, 2006 1 次提交
  11. 03 5月, 2006 1 次提交
  12. 26 4月, 2006 1 次提交
  13. 29 3月, 2006 1 次提交
  14. 20 2月, 2006 3 次提交
  15. 09 1月, 2006 1 次提交
  16. 25 12月, 2005 1 次提交
  17. 11 11月, 2005 3 次提交
  18. 26 10月, 2005 1 次提交
  19. 22 9月, 2005 1 次提交
  20. 14 9月, 2005 1 次提交
  21. 07 9月, 2005 1 次提交
  22. 19 8月, 2005 1 次提交
    • M
      [PATCH] forcedeth: Initialize link settings in every nv_open() · 1b1b3c9b
      Manfred Spraul 提交于
      Rüdiger found a bug in nv_open that explains some of the reports
      with duplex mismatches:
      nv_open calls nv_update_link_speed for initializing the hardware link speed
      registers. If current link setting matches the values in np->linkspeed and
      np->duplex, then the function does nothing.
      Usually, doing nothing is the right thing, but not in nv_open: During
      nv_open, the registers must be initialized because the nic was reset.
      
      The attached patch fixes that by setting np->linkspeed to an invalid value
      before calling nv_update_link_speed from nv_open.
      Signed-Off-By: NManfred Spraul <manfred@colorfullife.com>
      Signed-off-by: NJeff Garzik <jgarzik@pobox.com>
      1b1b3c9b
  23. 01 8月, 2005 1 次提交