1. 03 7月, 2014 29 次提交
  2. 20 5月, 2014 1 次提交
  3. 16 5月, 2014 1 次提交
  4. 28 3月, 2014 2 次提交
  5. 27 3月, 2014 2 次提交
  6. 13 3月, 2014 1 次提交
  7. 12 3月, 2014 1 次提交
    • A
      Bluetooth: Enable duplicates filter in background scan · 4340a124
      Andre Guedes 提交于
      To avoid flooding the host with useless advertising reports during
      background scan, we enable the duplicates filter from controller.
      
      However, enabling duplicates filter requires a small change in
      background scan routine in order to fix the following scenario:
        1) Background scan is running.
        2) A device disconnects and starts advertising.
        3) Before host gets the disconnect event, the advertising is reported
           to host. Since there is no pending LE connection at that time,
           nothing happens.
        4) Host gets the disconnection event and adds a pending connection.
        5) No advertising is reported (since controller is filtering) and the
           connection is never established.
      
      So, to address this scenario, we should always restart background scan
      to unsure we don't miss any advertising report (due to duplicates
      filter).
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      4340a124
  8. 28 2月, 2014 3 次提交
    • J
      Bluetooth: Add protections for updating local random address · 8d97250e
      Johan Hedberg 提交于
      Different controllers behave differently when HCI_Set_Random_Address is
      called while they are advertising or have a HCI_LE_Create_Connection in
      progress. Some take the newly written address into use for the pending
      operation while others use the random address that we had at the time
      that the operation started.
      
      Due to this undefined behavior and for the fact that we want to reliably
      determine the initiator address of all connections for the sake of SMP
      it's best to simply prevent the random address update if we have these
      problematic operations in progress.
      
      This patch adds a set_random_addr() helper function for the use of
      hci_update_random_address which contains the necessary checks for
      advertising and ongoing LE connections.
      
      One extra thing we need to do is to clear the HCI_ADVERTISING flag in
      the enable_advertising() function before sending any commands. Since
      re-enabling advertising happens by calling first disable_advertising()
      and then enable_advertising() all while having the HCI_ADVERTISING flag
      set. Clearing the flag lets the set_random_addr() function know that
      it's safe to write a new address at least as far as advertising is
      concerned.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      8d97250e
    • M
      Bluetooth: Use __le64 type for LE random numbers · fe39c7b2
      Marcel Holtmann 提交于
      The random numbers in Bluetooth Low Energy are 64-bit numbers and should
      also be little endian since the HCI specification is little endian.
      
      Change the whole Low Energy pairing to use __le64 instead of a byte
      array.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      fe39c7b2
    • M
      Bluetooth: Add support for storing LE white list entries · d2ab0ac1
      Marcel Holtmann 提交于
      The current LE white list entries require storing in the HCI controller
      structure. So provide a storage and access functions for it. In addition
      export the current list via debugfs.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      d2ab0ac1