1. 26 11月, 2021 1 次提交
  2. 16 11月, 2021 1 次提交
    • A
      Bluetooth: Ignore HCI_ERROR_CANCELLED_BY_HOST on adv set terminated event · 0f281a5e
      Archie Pusaka 提交于
      This event is received when the controller stops advertising,
      specifically for these three reasons:
      (a) Connection is successfully created (success).
      (b) Timeout is reached (error).
      (c) Number of advertising events is reached (error).
      (*) This event is NOT generated when the host stops the advertisement.
      Refer to the BT spec ver 5.3 vol 4 part E sec 7.7.65.18. Note that the
      section was revised from BT spec ver 5.0 vol 2 part E sec 7.7.65.18
      which was ambiguous about (*).
      
      Some chips (e.g. RTL8822CE) send this event when the host stops the
      advertisement with status = HCI_ERROR_CANCELLED_BY_HOST (due to (*)
      above). This is treated as an error and the advertisement will be
      removed and userspace will be informed via MGMT event.
      
      On suspend, we are supposed to temporarily disable advertisements,
      and continue advertising on resume. However, due to the behavior
      above, the advertisements are removed instead.
      
      This patch returns early if HCI_ERROR_CANCELLED_BY_HOST is received.
      
      Btmon snippet of the unexpected behavior:
      @ MGMT Command: Remove Advertising (0x003f) plen 1
              Instance: 1
      < HCI Command: LE Set Extended Advertising Enable (0x08|0x0039) plen 6
              Extended advertising: Disabled (0x00)
              Number of sets: 1 (0x01)
              Entry 0
                Handle: 0x01
                Duration: 0 ms (0x00)
                Max ext adv events: 0
      > HCI Event: LE Meta Event (0x3e) plen 6
            LE Advertising Set Terminated (0x12)
              Status: Operation Cancelled by Host (0x44)
              Handle: 1
              Connection handle: 0
              Number of completed extended advertising events: 5
      > HCI Event: Command Complete (0x0e) plen 4
            LE Set Extended Advertising Enable (0x08|0x0039) ncmd 2
              Status: Success (0x00)
      Signed-off-by: NArchie Pusaka <apusaka@chromium.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      0f281a5e
  3. 08 9月, 2021 5 次提交
  4. 30 8月, 2021 1 次提交
  5. 26 6月, 2021 6 次提交
  6. 04 3月, 2021 1 次提交
  7. 29 1月, 2021 1 次提交
    • H
      Bluetooth: Add new HCI_QUIRK_NO_SUSPEND_NOTIFIER quirk · 219991e6
      Hans de Goede 提交于
      Some devices, e.g. the RTL8723BS bluetooth part, some USB attached devices,
      completely drop from the bus on a system-suspend. These devices will
      have their driver unbound and rebound on resume (when the dropping of
      the bus gets detected) and will show up as a new HCI after resume.
      
      These devices do not benefit from the suspend / resume handling work done
      by the hci_suspend_notifier. At best this unnecessarily adds some time to
      the suspend/resume time. But this may also actually cause problems, if the
      code doing the driver unbinding runs after the pm-notifier then the
      hci_suspend_notifier code will try to talk to a device which is now in
      an uninitialized state.
      
      This commit adds a new HCI_QUIRK_NO_SUSPEND_NOTIFIER quirk which allows
      drivers to opt-out of the hci_suspend_notifier when they know beforehand
      that their device will be fully re-initialized / reprobed on resume.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Reviewed-by: NAbhishek Pandit-Subedi <abhishekpandit@chromium.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      219991e6
  8. 07 12月, 2020 1 次提交
  9. 30 7月, 2020 3 次提交
  10. 28 7月, 2020 1 次提交
  11. 22 6月, 2020 1 次提交
  12. 11 5月, 2020 1 次提交
  13. 28 4月, 2020 1 次提交
    • A
      Bluetooth: Adding driver and quirk defs for multi-role LE · 22091585
      Alain Michaud 提交于
      This change adds the relevant driver and quirk to allow drivers to
      report the le_states as being trustworthy.
      
      This has historically been disabled as controllers did not reliably
      support this. In particular, this will be used to relax this condition
      for controllers that have been well tested and reliable.
      
      	/* Most controller will fail if we try to create new connections
      	 * while we have an existing one in slave role.
      	 */
      	if (hdev->conn_hash.le_num_slave > 0)
      		return NULL;
      Signed-off-by: NAlain Michaud <alainm@chromium.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      22091585
  14. 15 4月, 2020 2 次提交
  15. 08 4月, 2020 1 次提交
  16. 05 4月, 2020 3 次提交
  17. 12 3月, 2020 1 次提交
  18. 08 3月, 2020 1 次提交
  19. 28 2月, 2020 4 次提交
  20. 16 1月, 2020 1 次提交
  21. 04 1月, 2020 1 次提交
  22. 06 7月, 2019 1 次提交
  23. 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