1. 17 2月, 2011 4 次提交
  2. 08 2月, 2011 11 次提交
  3. 08 12月, 2010 1 次提交
  4. 02 12月, 2010 2 次提交
  5. 12 10月, 2010 1 次提交
  6. 22 7月, 2010 2 次提交
  7. 27 2月, 2010 2 次提交
  8. 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
  9. 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
  10. 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
  11. 15 7月, 2008 7 次提交
    • 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
    • M
      [Bluetooth] Track status of remote Simple Pairing mode · 41a96212
      Marcel Holtmann 提交于
      The Simple Pairing process can only be used if both sides have the
      support enabled in the host stack. The current Bluetooth specification
      has three ways to detect this support.
      
      If an Extended Inquiry Result has been sent during inquiry then it
      is safe to assume that Simple Pairing is enabled. It is not allowed
      to enable Extended Inquiry without Simple Pairing. During the remote
      name request phase a notification with the remote host supported
      features will be sent to indicate Simple Pairing support. Also the
      second page of the remote extended features can indicate support for
      Simple Pairing.
      
      For all three cases the value of remote Simple Pairing mode is stored
      in the inquiry cache for later use.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      41a96212
    • M
      [Bluetooth] Track status of Simple Pairing mode · 333140b5
      Marcel Holtmann 提交于
      The Simple Pairing feature is optional and needs to be enabled by the
      host stack first. The Linux kernel relies on the Bluetooth daemon to
      either enable or disable it, but at any time it needs to know the
      current state of the Simple Pairing mode. So track any changes made
      by external entities and store the current mode in the HCI device
      structure.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      333140b5
    • M
      [Bluetooth] Disable disconnect timer during Simple Pairing · 0493684e
      Marcel Holtmann 提交于
      During the Simple Pairing process the HCI disconnect timer must be
      disabled. The way to do this is by holding a reference count of the
      HCI connection. The Simple Pairing process on both sides starts with
      an IO Capabilities Request and ends with Simple Pairing Complete.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      0493684e
    • M
      [Bluetooth] Make use of the default link policy settings · e4e8e37c
      Marcel Holtmann 提交于
      The Bluetooth specification supports the default link policy settings
      on a per host controller basis. For every new connection the link
      manager would then use these settings. It is better to use this instead
      of bothering the controller on every connection setup to overwrite the
      default settings.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      e4e8e37c
    • M
      [Bluetooth] Track connection packet type changes · a8746417
      Marcel Holtmann 提交于
      The connection packet type can be changed after the connection has been
      established and thus needs to be properly tracked to ensure that the
      host stack has always correct and valid information about it.
      
      On incoming connections the Bluetooth core switches the supported packet
      types to the configured list for this controller. However the usefulness
      of this feature has been questioned a lot. The general consent is that
      every Bluetooth host stack should enable as many packet types as the
      hardware actually supports and leave the decision to the link manager
      software running on the Bluetooth chip.
      
      When running on Bluetooth 2.0 or later hardware, don't change the packet
      type for incoming connections anymore. This hardware likely supports
      Enhanced Data Rate and thus leave it completely up to the link manager
      to pick the best packet type.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      a8746417
  12. 22 10月, 2007 1 次提交
    • M
      [Bluetooth] Switch from OGF+OCF to using only opcodes · a9de9248
      Marcel Holtmann 提交于
      The Bluetooth HCI commands are divided into logical OGF groups for
      easier identification of their purposes. While this still makes sense
      for the written specification, its makes the code only more complex
      and harder to read. So instead of using separate OGF and OCF values
      to identify the commands, use a common 16-bit opcode that combines
      both values. As a side effect this also reduces the complexity of
      OGF and OCF calculations during command header parsing.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      a9de9248
  13. 11 7月, 2007 1 次提交
  14. 26 4月, 2007 1 次提交
  15. 14 12月, 2006 1 次提交
  16. 29 9月, 2006 3 次提交