1. 16 10月, 2015 3 次提交
    • J
      Bluetooth: Fix LE reconnection logic · 49c50922
      Johan Hedberg 提交于
      We can't use hci_explicit_connect_lookup() since that would only cover
      explicit connections, leaving normal reconnections completely
      untouched. Not using it in turn means leaving out entries in
      pend_le_reports.
      
      To fix this and simplify the logic move conn params from the reports
      list to the pend_le_conns list for the duration of an explicit
      connect. Once the connect is complete move the params back to the
      pend_le_reports list. This also means that the explicit connect lookup
      function only needs to look into the pend_le_conns list.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      49c50922
    • J
      Bluetooth: Fix reference counting for LE-scan based connections · b958f9a3
      Johan Hedberg 提交于
      The code should never directly call hci_conn_hash_del since many
      cleanup & reference counting updates would be lost. Normally
      hci_conn_del is the right thing to do, but in the case of a connection
      doing LE scanning this could cause a deadlock due to doing a
      cancel_delayed_work_sync() on the same work callback that we were
      called from.
      
      Connections in the LE scanning state actually need very little cleanup
      - just a small subset of hci_conn_del. To solve the issue, refactor
      out these essential pieces into a new hci_conn_cleanup() function and
      call that from the two necessary places.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      b958f9a3
    • J
      Bluetooth: Fix double scan updates · 168b8a25
      Jakub Pawlowski 提交于
      When disable/enable scan command is issued twice, some controllers
      will return an error for the second request, i.e. requests with this
      command will fail on some controllers, and succeed on others.
      
      This patch makes sure that unnecessary scan disable/enable commands
      are not issued.
      
      When adding device to the auto connect whitelist when there is pending
      connect attempt, there is no need to update scan.
      
      hci_connect_le_scan_cleanup is conditionally executing
      hci_conn_params_del, that is calling hci_update_background_scan. Make
      the other case also update scan, and remove reduntand call from
      hci_connect_le_scan_remove.
      
      When stopping interleaved discovery the state should be set to stopped
      only when both LE scanning and discovery has stopped.
      Signed-off-by: NJakub Pawlowski <jpawlowski@google.com>
      Acked-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      168b8a25
  2. 11 8月, 2015 4 次提交
  3. 09 6月, 2015 1 次提交
  4. 13 3月, 2015 3 次提交
  5. 19 2月, 2015 2 次提交
  6. 14 2月, 2015 2 次提交
  7. 16 1月, 2015 1 次提交
  8. 12 1月, 2015 1 次提交
  9. 21 12月, 2014 1 次提交
  10. 19 12月, 2014 1 次提交
  11. 08 12月, 2014 1 次提交
  12. 05 12月, 2014 1 次提交
  13. 29 10月, 2014 2 次提交
  14. 26 10月, 2014 1 次提交
  15. 25 10月, 2014 1 次提交
  16. 25 9月, 2014 2 次提交
  17. 24 9月, 2014 1 次提交
    • J
      Bluetooth: Fix reason code used for rejecting SCO connections · d41c15cf
      Johan Hedberg 提交于
      The core specification defines valid values for the
      HCI_Reject_Synchronous_Connection_Request command to be 0x0D-0x0F. So
      far the code has been using HCI_ERROR_REMOTE_USER_TERM (0x13) which is
      not a valid value and is therefore being rejected by some controllers:
      
       > HCI Event: Connect Request (0x04) plen 10
      	bdaddr 40:6F:2A:6A:E5:E0 class 0x000000 type eSCO
       < HCI Command: Reject Synchronous Connection (0x01|0x002a) plen 7
      	bdaddr 40:6F:2A:6A:E5:E0 reason 0x13
      	Reason: Remote User Terminated Connection
       > HCI Event: Command Status (0x0f) plen 4
      	Reject Synchronous Connection (0x01|0x002a) status 0x12 ncmd 1
      	Error: Invalid HCI Command Parameters
      
      This patch introduces a new define for a value from the valid range
      (0x0d == Connection Rejected Due To Limited Resources) and uses it
      instead for rejecting incoming connections.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      d41c15cf
  18. 23 9月, 2014 1 次提交
  19. 09 9月, 2014 7 次提交
  20. 21 8月, 2014 1 次提交
    • J
      Bluetooth: Fix hci_conn reference counting for auto-connections · f161dd41
      Johan Hedberg 提交于
      Recently the LE passive scanning and auto-connections feature was
      introduced. It uses the hci_connect_le() API which returns a hci_conn
      along with a reference count to that object. All previous users would
      tie this returned reference to some existing object, such as an L2CAP
      channel, and there'd be no leaked references this way. For
      auto-connections however the reference was returned but not stored
      anywhere, leaving established connections with one higher reference
      count than they should have.
      
      Instead of playing special tricks with hci_conn_hold/drop this patch
      associates the returned reference from hci_connect_le() with the object
      that in practice does own this reference, i.e. the hci_conn_params
      struct that caused us to initiate a connection in the first place. Once
      the connection is established or fails to establish this reference is
      removed appropriately.
      
      One extra thing needed is to call hci_pend_le_actions_clear() before
      calling hci_conn_hash_flush() so that the reference is cleared before
      the hci_conn objects are fully removed.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      f161dd41
  21. 21 7月, 2014 1 次提交
  22. 18 7月, 2014 1 次提交
  23. 17 7月, 2014 1 次提交