1. 07 7月, 2011 3 次提交
  2. 14 6月, 2011 1 次提交
  3. 09 6月, 2011 2 次提交
  4. 29 4月, 2011 1 次提交
  5. 25 4月, 2011 1 次提交
  6. 01 4月, 2011 5 次提交
  7. 25 3月, 2011 1 次提交
  8. 22 2月, 2011 1 次提交
  9. 17 2月, 2011 4 次提交
  10. 08 2月, 2011 11 次提交
  11. 08 12月, 2010 1 次提交
  12. 02 12月, 2010 2 次提交
  13. 12 10月, 2010 1 次提交
  14. 22 7月, 2010 2 次提交
  15. 27 2月, 2010 2 次提交
  16. 29 4月, 2009 1 次提交
    • M
      Bluetooth: Add different pairing timeout for Legacy Pairing · 052b30b0
      Marcel Holtmann 提交于
      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: NMarcel Holtmann <marcel@holtmann.org>
      052b30b0
  17. 27 2月, 2009 1 次提交
    • M
      Bluetooth: Add SCO fallback for eSCO connection attempts · efc7688b
      Marcel Holtmann 提交于
      When attempting to setup eSCO connections it can happen that some link
      manager implementations fail to properly negotiate the eSCO parameters
      and thus fail the eSCO setup. Normally the link manager is responsible
      for the negotiation of the parameters and actually fallback to SCO if
      no agreement can be reached. In cases where the link manager is just too
      stupid, then at least try to establish a SCO link if eSCO fails.
      
      For the Bluetooth devices with EDR support this includes handling packet
      types of EDR basebands. This is particular tricky since for the EDR the
      logic of enabling/disabling one specific packet type is turned around.
      This fix contains an extra bitmask to disable eSCO EDR packet when
      trying to fallback to a SCO connection.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      efc7688b