1. 02 May, 2009 1 commit
  2. 01 May, 2009 2 commits
  3. 30 Apr, 2009 21 commits
  4. 29 Apr, 2009 10 commits
  5. 28 Apr, 2009 6 commits
    • Bob Copeland's avatar
      ath5k: fix buffer overrun in rate debug code · b7fcb5c4
      Bob Copeland authored
      char bname[5] is too small for the string "X GHz" when the null
      terminator is taken into account.  Thus, turning on rate debugging
      can crash unless we have lucky stack alignment.
      
      Cc: stable@kernel.org
      Reported-by: default avatarParide Legovini <legovini@spiro.fisica.unipd.it>
      Signed-off-by: default avatarBob Copeland <me@bobcopeland.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      b7fcb5c4
    • Johannes Berg's avatar
      iwlwifi: notify on scan completion even when shutting down · 74aa9be0
      Johannes Berg authored
      Under certain circumstances iwlwifi can get stuck and will no
      longer accept scan requests, because the core code (cfg80211)
      thinks that it's still processing one. This fixes one of the
      points where it can happen, but I've still seen it (although
      only with my radio-off-when-idle patch).
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Acked-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      74aa9be0
    • Jussi Kivilinna's avatar
      rndis_wlan: fix initialization order for workqueue&workers · e805e4d0
      Jussi Kivilinna authored
      rndis_wext_link_change() might be called from rndis_command() at
      initialization stage and priv->workqueue/priv->work have not been
      initialized yet. This causes invalid opcode at rndis_wext_bind on
      some brands of bcm4320.
      
      Fix by initializing workqueue/workers in rndis_wext_bind() before
      rndis_command is used.
      
      This bug has existed since 2.6.25, reported at:
      	http://bugzilla.kernel.org/show_bug.cgi?id=12794Signed-off-by: default avatarJussi Kivilinna <jussi.kivilinna@mbnet.fi>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      e805e4d0
    • Stephen Rothwell's avatar
      wireless: remove unneeded EXPORT_SYMBOL the tickles a powerpc compiler bug · 6269b731
      Stephen Rothwell authored
      drivers/net/wireless/iwlwifi/iwl3945-base.c:1415: error: __ksymtab_iwl3945_rx_queue_reset causes a section type conflict
      
      I am pretty sure that this is a compiler bug, so not to worry.  However,
      as far as I can see, iwl-3945.o (the only user) and iwl3945-base.o are
      always linked into the same module, so the EXPORT_SYMBOL (which causes
      the problem) should not be needed.  Correct?
      Signed-off-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      6269b731
    • Marcel Holtmann's avatar
      Bluetooth: Fix connection establishment with low security requirement · 3fdca1e1
      Marcel Holtmann authored
      The Bluetooth 2.1 specification introduced four different security modes
      that can be mapped using Legacy Pairing and Simple Pairing. With the
      usage of Simple Pairing it is required that all connections (except
      the ones for SDP) are encrypted. So even the low security requirement
      mandates an encrypted connection when using Simple Pairing. When using
      Legacy Pairing (for Bluetooth 2.0 devices and older) this is not required
      since it causes interoperability issues.
      
      To support this properly the low security requirement translates into
      different host controller transactions depending if Simple Pairing is
      supported or not. However in case of Simple Pairing the command to
      switch on encryption after a successful authentication is not triggered
      for the low security mode. This patch fixes this and actually makes
      the logic to differentiate between Simple Pairing and Legacy Pairing
      a lot simpler.
      
      Based on a report by Ville Tervo <ville.tervo@nokia.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      3fdca1e1
    • Marcel Holtmann's avatar
      Bluetooth: Add different pairing timeout for Legacy Pairing · 052b30b0
      Marcel Holtmann authored
      The Bluetooth stack uses a reference counting for all established ACL
      links and if no user (L2CAP connection) is present, the link will be
      terminated to save power. The problem part is the dedicated pairing
      when using Legacy Pairing (Bluetooth 2.0 and before). At that point
      no user is present and pairing attempts will be disconnected within
      10 seconds or less. In previous kernel version this was not a problem
      since the disconnect timeout wasn't triggered on incoming connections
      for the first time. However this caused issues with broken host stacks
      that kept the connections around after dedicated pairing. When the
      support for Simple Pairing got added, the link establishment procedure
      needed to be changed and now causes issues when using Legacy Pairing
      
      When using Simple Pairing it is possible to do a proper reference
      counting of ACL link users. With Legacy Pairing this is not possible
      since the specification is unclear in some areas and too many broken
      Bluetooth devices have already been deployed. So instead of trying to
      deal with all the broken devices, a special pairing timeout will be
      introduced that increases the timeout to 60 seconds when pairing is
      triggered.
      
      If a broken devices now puts the stack into an unforeseen state, the
      worst that happens is the disconnect timeout triggers after 120 seconds
      instead of 4 seconds. This allows successful pairings with legacy and
      broken devices now.
      
      Based on a report by Johan Hedberg <johan.hedberg@nokia.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      052b30b0