1. 14 6月, 2011 1 次提交
  2. 09 6月, 2011 2 次提交
  3. 29 4月, 2011 1 次提交
  4. 25 4月, 2011 1 次提交
  5. 01 4月, 2011 5 次提交
  6. 25 3月, 2011 1 次提交
  7. 22 2月, 2011 1 次提交
  8. 17 2月, 2011 4 次提交
  9. 08 2月, 2011 11 次提交
  10. 08 12月, 2010 1 次提交
  11. 02 12月, 2010 2 次提交
  12. 12 10月, 2010 1 次提交
  13. 22 7月, 2010 2 次提交
  14. 27 2月, 2010 2 次提交
  15. 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
  16. 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
  17. 30 11月, 2008 1 次提交
    • M
      Bluetooth: Send HCI Reset command by default on device initialization · 7a9d4020
      Marcel Holtmann 提交于
      The Bluetooth subsystem was not using the HCI Reset command when doing
      device initialization. The Bluetooth 1.0b specification was ambiguous
      on how the device firmware was suppose to handle it. Almost every device
      was triggering a transport reset at the same time. In case of USB this
      ended up in disconnects from the bus.
      
      All modern Bluetooth dongles handle this perfectly fine and a lot of
      them actually require that HCI Reset is sent. If not then they are
      either stuck in their HID Proxy mode or their internal structures for
      inquiry and paging are not correctly setup.
      
      To handle old and new devices smoothly the Bluetooth subsystem contains
      a quirk to force the HCI Reset on initialization. However maintaining
      such a quirk becomes more and more complicated. This patch turns the
      logic around and lets the old devices disable the HCI Reset command.
      
      The only device where the HCI_QUIRK_NO_RESET is still needed are the
      original Digianswer devices and dongles with an early CSR firmware.
      
      CSR reported that they fixed this for version 12 firmware. The last
      official release of version 11 firmware is build ID 115. The first
      version 12 candidate was build ID 117.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      7a9d4020
  18. 15 7月, 2008 2 次提交
    • M
      [Bluetooth] Export details about authentication requirements · 40be492f
      Marcel Holtmann 提交于
      With the Simple Pairing support, the authentication requirements are
      an explicit setting during the bonding process. Track and enforce the
      requirements and allow higher layers like L2CAP and RFCOMM to increase
      them if needed.
      
      This patch introduces a new IOCTL that allows to query the current
      authentication requirements. It is also possible to detect Simple
      Pairing support in the kernel this way.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      40be492f
    • M
      [Bluetooth] Use ACL config stage to retrieve remote features · 769be974
      Marcel Holtmann 提交于
      The Bluetooth technology introduces new features on a regular basis
      and for some of them it is important that the hardware on both sides
      support them. For features like Simple Pairing it is important that
      the host stacks on both sides have switched this feature on. To make
      valid decisions, a config stage during ACL link establishment has been
      introduced that retrieves remote features and if needed also the remote
      extended features (known as remote host features) before signalling
      this link as connected.
      
      This change introduces full reference counting of incoming and outgoing
      ACL links and the Bluetooth core will disconnect both if no owner of it
      is present. To better handle interoperability during the pairing phase
      the disconnect timeout for incoming connections has been increased to
      10 seconds. This is five times more than for outgoing connections.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      769be974