1. 22 12月, 2009 1 次提交
    • J
      mac80211: fix peer HT capabilities · 9a418af5
      Johannes Berg 提交于
      I noticed yesterday, because Jeff had noticed
      a speed regression, cf. bug
      http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2138
      that the SM PS settings for peers were wrong.
      Instead of overwriting the SM PS settings with
      the local bits, we need to keep the remote bits.
      
      The bug was part of the original HT code from
      over two years ago, but unfortunately nobody
      noticed that it makes no sense -- we shouldn't
      be overwriting the peer's setting with our own
      but rather keep it intact when masking the peer
      capabilities with our own.
      
      While fixing that, I noticed that the masking of
      capabilities is completely useless for most of
      the bits, so also fix those other bits.
      
      Finally, I also noticed that PSMP_SUPPORT no
      longer exists in the final 802.11n version, so
      also remove that.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9a418af5
  2. 16 12月, 2009 1 次提交
    • D
      tcp: Revert per-route SACK/DSACK/TIMESTAMP changes. · bb5b7c11
      David S. Miller 提交于
      It creates a regression, triggering badness for SYN_RECV
      sockets, for example:
      
      [19148.022102] Badness at net/ipv4/inet_connection_sock.c:293
      [19148.022570] NIP: c02a0914 LR: c02a0904 CTR: 00000000
      [19148.023035] REGS: eeecbd30 TRAP: 0700   Not tainted  (2.6.32)
      [19148.023496] MSR: 00029032 <EE,ME,CE,IR,DR>  CR: 24002442  XER: 00000000
      [19148.024012] TASK = eee9a820[1756] 'privoxy' THREAD: eeeca000
      
      This is likely caused by the change in the 'estab' parameter
      passed to tcp_parse_options() when invoked by the functions
      in net/ipv4/tcp_minisocks.c
      
      But even if that is fixed, the ->conn_request() changes made in
      this patch series is fundamentally wrong.  They try to use the
      listening socket's 'dst' to probe the route settings.  The
      listening socket doesn't even have a route, and you can't
      get the right route (the child request one) until much later
      after we setup all of the state, and it must be done by hand.
      
      This stuff really isn't ready, so the best thing to do is a
      full revert.  This reverts the following commits:
      
      f55017a9
      022c3f7d
      1aba721e
      cda42ebd
      345cda2f
      dc343475
      05eaade2
      6a2a2d6bSigned-off-by: NDavid S. Miller <davem@davemloft.net>
      bb5b7c11
  3. 14 12月, 2009 1 次提交
    • O
      can: Fix data length code handling in rx path · c7cd606f
      Oliver Hartkopp 提交于
      A valid CAN dataframe can have a data length code (DLC) of 0 .. 8 data bytes.
      
      When reading the CAN controllers register the 4-bit value may contain values
      from 0 .. 15 which may exceed the reserved space in the socket buffer!
      
      The ISO 11898-1 Chapter 8.4.2.3 (DLC field) says that register values > 8
      should be reduced to 8 without any error reporting or frame drop.
      
      This patch introduces a new helper macro to cast a given 4-bit data length
      code (dlc) to __u8 and ensure the DLC value to be max. 8 bytes.
      
      The different handlings in the rx path of the CAN netdevice drivers are fixed.
      Signed-off-by: NOliver Hartkopp <oliver@hartkopp.net>
      Signed-off-by: NWolfgang Grandegger <wg@grandegger.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c7cd606f
  4. 12 12月, 2009 19 次提交
  5. 11 12月, 2009 1 次提交
  6. 10 12月, 2009 6 次提交
  7. 09 12月, 2009 4 次提交
  8. 08 12月, 2009 1 次提交
  9. 07 12月, 2009 2 次提交
  10. 06 12月, 2009 4 次提交