1. 07 7月, 2020 2 次提交
  2. 18 6月, 2020 6 次提交
  3. 12 6月, 2020 2 次提交
  4. 08 6月, 2020 1 次提交
  5. 13 5月, 2020 2 次提交
  6. 16 4月, 2020 1 次提交
  7. 15 4月, 2020 1 次提交
  8. 05 4月, 2020 2 次提交
  9. 03 4月, 2020 1 次提交
    • A
      Bluetooth: Prioritize SCO traffic · 7fedd3bb
      Abhishek Pandit-Subedi 提交于
      When scheduling TX packets, send all SCO/eSCO packets first, check for
      pending SCO/eSCO packets after every ACL/LE packet and send them if any
      are pending.  This is done to make sure that we can meet SCO deadlines
      on slow interfaces like UART.
      
      If we were to queue up multiple ACL packets without checking for a SCO
      packet, we might miss the SCO timing. For example:
      
      The time it takes to send a maximum size ACL packet (1024 bytes):
      t = 10/8 * 1024 bytes * 8 bits/byte * 1 packet / baudrate
              where 10/8 is uart overhead due to start/stop bits per byte
      
      Replace t = 3.75ms (SCO deadline), which gives us a baudrate of 2730666.
      
      At a baudrate of 3000000, if we didn't check for SCO packets within 1024
      bytes, we would miss the 3.75ms timing window.
      Signed-off-by: NAbhishek Pandit-Subedi <abhishekpandit@chromium.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      7fedd3bb
  10. 24 3月, 2020 1 次提交
  11. 12 3月, 2020 2 次提交
  12. 11 3月, 2020 1 次提交
  13. 08 3月, 2020 1 次提交
  14. 07 3月, 2020 1 次提交
  15. 28 2月, 2020 2 次提交
    • M
      Bluetooth: Use list_for_each_entry_rcu() to traverse RCU list in RCU read-side CS · 0c2ac7d4
      Madhuparna Bhowmik 提交于
      In function hci_is_blocked_key() RCU list is traversed with
      list_for_each_entry() in RCU read-side CS.
      Use list_for_each_entry_rcu() instead.
      Signed-off-by: NMadhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      0c2ac7d4
    • M
      Bluetooth: Fix Suspicious RCU usage warnings · d7d41682
      Madhuparna Bhowmik 提交于
      The following functions in hci_core are always called with
      hdev->lock held. No need to use list_for_each_entry_rcu(), therefore
      change the usage of list_for_each_entry_rcu() in these functions
      to list_for_each_entry().
      
      hci_link_keys_clear()
      hci_smp_ltks_clear()
      hci_smp_irks_clear()
      hci_blocked_keys_clear()
      
      Warning encountered with CONFIG_PROVE_RCU_LIST:
      
      [   72.213184] =============================
      [   72.213188] WARNING: suspicious RCU usage
      [   72.213192] 5.6.0-rc1+ #5 Not tainted
      [   72.213195] -----------------------------
      [   72.213198] net/bluetooth/hci_core.c:2288 RCU-list traversed in non-reader section!!
      
      [   72.213676] =============================
      [   72.213679] WARNING: suspicious RCU usage
      [   72.213683] 5.6.0-rc1+ #5 Not tainted
      [   72.213685] -----------------------------
      [   72.213689] net/bluetooth/hci_core.c:2298 RCU-list traversed in non-reader section!!
      
      [   72.214195] =============================
      [   72.214198] WARNING: suspicious RCU usage
      [   72.214201] 5.6.0-rc1+ #5 Not tainted
      [   72.214204] -----------------------------
      [   72.214208] net/bluetooth/hci_core.c:2308 RCU-list traversed in non-reader section!!
      
      [  333.456972] =============================
      [  333.456979] WARNING: suspicious RCU usage
      [  333.457001] 5.6.0-rc1+ #5 Not tainted
      [  333.457007] -----------------------------
      [  333.457014] net/bluetooth/hci_core.c:2318 RCU-list traversed in non-reader section!!
      Signed-off-by: NMadhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      d7d41682
  16. 25 1月, 2020 1 次提交
  17. 16 1月, 2020 2 次提交
  18. 22 11月, 2019 1 次提交
  19. 17 10月, 2019 2 次提交
  20. 17 8月, 2019 1 次提交
  21. 06 7月, 2019 2 次提交
  22. 06 5月, 2019 1 次提交
    • J
      Bluetooth: Ignore CC events not matching the last HCI command · f80c5dad
      João Paulo Rechi Vita 提交于
      This commit makes the kernel not send the next queued HCI command until
      a command complete arrives for the last HCI command sent to the
      controller. This change avoids a problem with some buggy controllers
      (seen on two SKUs of QCA9377) that send an extra command complete event
      for the previous command after the kernel had already sent a new HCI
      command to the controller.
      
      The problem was reproduced when starting an active scanning procedure,
      where an extra command complete event arrives for the LE_SET_RANDOM_ADDR
      command. When this happends the kernel ends up not processing the
      command complete for the following commmand, LE_SET_SCAN_PARAM, and
      ultimately behaving as if a passive scanning procedure was being
      performed, when in fact controller is performing an active scanning
      procedure. This makes it impossible to discover BLE devices as no device
      found events are sent to userspace.
      
      This problem is reproducible on 100% of the attempts on the affected
      controllers. The extra command complete event can be seen at timestamp
      27.420131 on the btmon logs bellow.
      
      Bluetooth monitor ver 5.50
      = Note: Linux version 5.0.0+ (x86_64)                                  0.352340
      = Note: Bluetooth subsystem version 2.22                               0.352343
      = New Index: 80:C5:F2:8F:87:84 (Primary,USB,hci0)               [hci0] 0.352344
      = Open Index: 80:C5:F2:8F:87:84                                 [hci0] 0.352345
      = Index Info: 80:C5:F2:8F:87:84 (Qualcomm)                      [hci0] 0.352346
      @ MGMT Open: bluetoothd (privileged) version 1.14             {0x0001} 0.352347
      @ MGMT Open: btmon (privileged) version 1.14                  {0x0002} 0.352366
      @ MGMT Open: btmgmt (privileged) version 1.14                {0x0003} 27.302164
      @ MGMT Command: Start Discovery (0x0023) plen 1       {0x0003} [hci0] 27.302310
              Address type: 0x06
                LE Public
                LE Random
      < HCI Command: LE Set Random Address (0x08|0x0005) plen 6   #1 [hci0] 27.302496
              Address: 15:60:F2:91:B2:24 (Non-Resolvable)
      > HCI Event: Command Complete (0x0e) plen 4                 #2 [hci0] 27.419117
            LE Set Random Address (0x08|0x0005) ncmd 1
              Status: Success (0x00)
      < HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7  #3 [hci0] 27.419244
              Type: Active (0x01)
              Interval: 11.250 msec (0x0012)
              Window: 11.250 msec (0x0012)
              Own address type: Random (0x01)
              Filter policy: Accept all advertisement (0x00)
      > HCI Event: Command Complete (0x0e) plen 4                 #4 [hci0] 27.420131
            LE Set Random Address (0x08|0x0005) ncmd 1
              Status: Success (0x00)
      < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2      #5 [hci0] 27.420259
              Scanning: Enabled (0x01)
              Filter duplicates: Enabled (0x01)
      > HCI Event: Command Complete (0x0e) plen 4                 #6 [hci0] 27.420969
            LE Set Scan Parameters (0x08|0x000b) ncmd 1
              Status: Success (0x00)
      > HCI Event: Command Complete (0x0e) plen 4                 #7 [hci0] 27.421983
            LE Set Scan Enable (0x08|0x000c) ncmd 1
              Status: Success (0x00)
      @ MGMT Event: Command Complete (0x0001) plen 4        {0x0003} [hci0] 27.422059
            Start Discovery (0x0023) plen 1
              Status: Success (0x00)
              Address type: 0x06
                LE Public
                LE Random
      @ MGMT Event: Discovering (0x0013) plen 2             {0x0003} [hci0] 27.422067
              Address type: 0x06
                LE Public
                LE Random
              Discovery: Enabled (0x01)
      @ MGMT Event: Discovering (0x0013) plen 2             {0x0002} [hci0] 27.422067
              Address type: 0x06
                LE Public
                LE Random
              Discovery: Enabled (0x01)
      @ MGMT Event: Discovering (0x0013) plen 2             {0x0001} [hci0] 27.422067
              Address type: 0x06
                LE Public
                LE Random
              Discovery: Enabled (0x01)
      Signed-off-by: NJoão Paulo Rechi Vita <jprvita@endlessm.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      f80c5dad
  23. 24 4月, 2019 1 次提交
  24. 26 2月, 2019 1 次提交
  25. 25 1月, 2019 2 次提交