1. 29 12月, 2010 1 次提交
  2. 26 12月, 2010 2 次提交
  3. 24 12月, 2010 1 次提交
  4. 23 12月, 2010 1 次提交
  5. 21 12月, 2010 4 次提交
  6. 18 12月, 2010 2 次提交
  7. 17 12月, 2010 7 次提交
  8. 16 12月, 2010 1 次提交
  9. 15 12月, 2010 1 次提交
  10. 14 12月, 2010 2 次提交
  11. 13 12月, 2010 6 次提交
  12. 11 12月, 2010 4 次提交
  13. 10 12月, 2010 4 次提交
    • T
      hso: IP checksuming doesn't work on GE0301 option cards · 6934d335
      Thomas Bogendoerfer 提交于
      There is definitly a problem, that some option cards send up broken
      IP pakets leading to corrupted IP packets. These corruptions aren't
      detected, because the driver claims that the packets are already
      checksummed. This change removes the CHECKSUM_UNNECESSARY option
      and let IP detect broken data.
      Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6934d335
    • N
      net: Convert netpoll blocking api in bonding driver to be a counter · fb4fa76a
      Neil Horman 提交于
      A while back I made some changes to enable netpoll in the bonding driver.  Among
      them was a per-cpu flag that indicated we were in a path that held locks which
      could cause the netpoll path to block in during tx, and as such the tx path
      should queue the frame for later use.  This appears to have given rise to a
      regression.  If one of those paths on which we hold the per-cpu flag yields the
      cpu, its possible for us to come back on a different cpu, leading to us clearing
      a different flag than we set.  This results in odd netpoll drops, and BUG
      backtraces appearing in the log, as we check to make sure that we only clear set
      bits, and only set clear bits.  I had though briefly about changing the
      offending paths so that they wouldn't sleep, but looking at my origional work
      more closely, it doesn't appear that a per-cpu flag is warranted.  We alrady
      gate the checking of this flag on IFF_IN_NETPOLL, so we don't hit this in the
      normal tx case anyway.  And practically speaking, the normal use case for
      netpoll is to only have one client anyway, so we're not going to erroneously
      queue netpoll frames when its actually safe to do so.  As such, lets just
      convert that per-cpu flag to an atomic counter.  It fixes the rescheduling bugs,
      is equivalent from a performance perspective and actually eliminates some code
      in the process.
      
      Tested by the reporter and myself, successfully
      Reported-by: NLiang Zheng <lzheng@redhat.com>
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: David S. Miller <davem@davemloft.net>
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fb4fa76a
    • W
      iwlagn: implement layout-agnostic EEPROM reading · 6942fec9
      Wey-Yi Guy 提交于
      From: Johannes Berg <johannes.berg@intel.com>
      
      The current EEPROM reading code has some layout
      assumptions that now turned out to be false with
      some newer versions of the EEPROM. Luckily, we
      can avoid all such assumptions by using data in
      the EEPROM itself, so implement using that.
      
      However, for risk mitigation purposes, keep the
      old reading code for current hardware for now.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      6942fec9
    • J
      iwlagn: rename enhanced txpower fields · cbf68a66
      Johannes Berg 提交于
      Some fields we didn't previously use from the
      enhanced TX power structure will be needed in
      the next patch, so rename them to their correct
      names to be able to use them and change code
      reading them accordingly.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      cbf68a66
  14. 09 12月, 2010 4 次提交
    • D
      orinoco: fix TKIP countermeasure behaviour · 0a54917c
      David Kilroy 提交于
      Enable the port when disabling countermeasures, and disable it on
      enabling countermeasures.
      
      This bug causes the response of the system to certain attacks to be
      ineffective.
      
      It also prevents wpa_supplicant from getting scan results, as
      wpa_supplicant disables countermeasures on startup - preventing the
      hardware from scanning.
      
      wpa_supplicant works with ap_mode=2 despite this bug because the commit
      handler re-enables the port.
      
      The log tends to look like:
      
      State: DISCONNECTED -> SCANNING
      Starting AP scan for wildcard SSID
      Scan requested (ret=0) - scan timeout 5 seconds
      EAPOL: disable timer tick
      EAPOL: Supplicant port status: Unauthorized
      Scan timeout - try to get results
      Failed to get scan results
      Failed to get scan results - try scanning again
      Setting scan request: 1 sec 0 usec
      Starting AP scan for wildcard SSID
      Scan requested (ret=-1) - scan timeout 5 seconds
      Failed to initiate AP scan.
      
      Reported by: Giacomo Comes <comes@naic.edu>
      Signed-off by: David Kilroy <kilroyd@googlemail.com>
      Cc: stable@kernel.org
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0a54917c
    • D
      orinoco: clear countermeasure setting on commit · ba34fcee
      David Kilroy 提交于
      ... and interface up.
      
      In these situations, you are usually trying to connect to a new AP, so
      keeping TKIP countermeasures active is confusing. This is already how
      the driver behaves (inadvertently). However, querying SIOCGIWAUTH may
      tell userspace that countermeasures are active when they aren't.
      
      Clear the setting so that the reporting matches what the driver has
      done..
      
      Signed-off by: David Kilroy <kilroyd@googlemail.com>
      Cc: stable@kernel.org
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ba34fcee
    • S
      ath9k_htc: Fix suspend/resume · f933ebed
      Sujith Manoharan 提交于
      The HW has to be set to FULLSLEEP mode during suspend,
      when no interface has been brought up. Not doing this would
      break resume, as the chip won't be powered up at all.
      Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f933ebed
    • J
      b93996cf