1. 15 7月, 2020 1 次提交
  2. 08 7月, 2020 1 次提交
  3. 07 7月, 2020 1 次提交
  4. 25 6月, 2020 1 次提交
  5. 22 6月, 2020 1 次提交
  6. 18 6月, 2020 3 次提交
  7. 12 6月, 2020 1 次提交
  8. 04 6月, 2020 1 次提交
  9. 13 5月, 2020 3 次提交
  10. 11 5月, 2020 1 次提交
  11. 15 4月, 2020 1 次提交
  12. 18 3月, 2020 1 次提交
  13. 12 3月, 2020 4 次提交
  14. 11 3月, 2020 1 次提交
  15. 04 11月, 2019 1 次提交
  16. 26 10月, 2019 2 次提交
  17. 05 9月, 2019 1 次提交
  18. 06 7月, 2019 1 次提交
  19. 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
  20. 19 12月, 2018 1 次提交
  21. 30 7月, 2018 6 次提交
    • J
      Bluetooth: Implement secondary advertising on different PHYs · 85a721a8
      Jaganath Kanakkassery 提交于
      This patch adds support for advertising in primary and secondary
      channel on different PHYs. User can add the phy preference in
      the flag based on which phy type will be added in extended
      advertising parameter would be set.
      
      @ MGMT Command: Add Advertising (0x003e) plen 11
              Instance: 1
              Flags: 0x00000200
                Advertise in CODED on Secondary channel
              Duration: 0
              Timeout: 0
              Advertising data length: 0
              Scan response length: 0
      < HCI Command: LE Set Extended Advertising Enable (0x08|0x0039) plen 2
              Extended advertising: Disabled (0x00)
              Number of sets: Disable all sets (0x00)
      > HCI Event: Command Complete (0x0e) plen 4
            LE Set Extended Advertising Enable (0x08|0x0039) ncmd 2
              Status: Success (0x00)
      < HCI Command: LE Set Extended Advertising Parameters (0x08|0x0036) plen 25
              Handle: 0x00
              Properties: 0x0000
              Min advertising interval: 1280.000 msec (0x0800)
              Max advertising interval: 1280.000 msec (0x0800)
              Channel map: 37, 38, 39 (0x07)
              Own address type: Random (0x01)
              Peer address type: Public (0x00)
              Peer address: 00:00:00:00:00:00 (OUI 00-00-00)
              Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
              TX power: 127 dbm (0x7f)
              Primary PHY: LE Coded (0x03)
              Secondary max skip: 0x00
              Secondary PHY: LE Coded (0x03)
              SID: 0x00
              Scan request notifications: Disabled (0x00)
      Signed-off-by: NJaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      85a721a8
    • J
      Bluetooth: Implement Set ADV set random address · a73c046a
      Jaganath Kanakkassery 提交于
      This basically sets the random address for the adv instance
      Random address can be set only if the instance is created which
      is done in Set ext adv param.
      
      Random address and rpa expire timer and flags have been added
      to adv instance which will be used when the respective
      instance is scheduled.
      
      This introduces a hci_get_random_address() which returns the
      own address type and random address (rpa or nrpa) based
      on the instance flags and hdev flags. New function is required
      since own address type should be known before setting adv params
      but address can be set only after setting params.
      
      < HCI Command: LE Set Advertising Set Random Address (0x08|0x0035) plen 7
              Advertising handle: 0x00
              Advertising random address: 3C:8E:56:9B:77:84 (OUI 3C-8E-56)
      > HCI Event: Command Complete (0x0e) plen 4
            LE Set Advertising Set Random Address (0x08|0x0035) ncmd 1
              Status: Success (0x00)
      Signed-off-by: NJaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      a73c046a
    • J
      Bluetooth: Implement disable and removal of adv instance · 45b7749f
      Jaganath Kanakkassery 提交于
      If ext adv is enabled then use ext adv to disable as well.
      Also remove the adv set during LE disable.
      
      < HCI Command: LE Set Extended Advertising Enable (0x08|0x0039) plen 2
              Extended advertising: Disabled (0x00)
              Number of sets: Disable all sets (0x00)
      > HCI Event: Command Complete (0x0e) plen 4
            LE Set Extended Advertising Enable (0x08|0x0039) ncmd 2
              Status: Success (0x00)
      Signed-off-by: NJaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      45b7749f
    • J
      Bluetooth: Use Set ext adv/scan rsp data if controller supports · a0fb3726
      Jaganath Kanakkassery 提交于
      This patch implements Set Ext Adv data and Set Ext Scan rsp data
      if controller support extended advertising.
      
      Currently the operation is set as Complete data and fragment
      preference is set as no fragment
      
      < HCI Command: LE Set Extended Advertising Data (0x08|0x0037) plen 35
              Handle: 0x00
              Operation: Complete extended advertising data (0x03)
              Fragment preference: Minimize fragmentation (0x01)
              Data length: 0x15
              16-bit Service UUIDs (complete): 2 entries
                Heart Rate (0x180d)
                Battery Service (0x180f)
              Name (complete): Test LE
              Company: Google (224)
                Data: 0102
      > HCI Event: Command Complete (0x0e) plen 4
            LE Set Extended Advertising Data (0x08|0x0037) ncmd 1
              Status: Success (0x00)
      Signed-off-by: NJaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      a0fb3726
    • J
      Bluetooth: Impmlement extended adv enable · de181e88
      Jaganath Kanakkassery 提交于
      This patch basically replaces legacy adv with extended adv
      based on the controller support. Currently there is no
      design change. ie only one adv set will be enabled at a time.
      
      This also adds tx_power in instance and store whatever returns
      from Set_ext_parameter, use the same in adv data as well.
      For instance 0 tx_power is stored in hdev only.
      
      < HCI Command: LE Set Extended Advertising Parameters (0x08|0x0036) plen 25
              Handle: 0x00
              Properties: 0x0010
                Use legacy advertising PDUs: ADV_NONCONN_IND
              Min advertising interval: 1280.000 msec (0x0800)
              Max advertising interval: 1280.000 msec (0x0800)
              Channel map: 37, 38, 39 (0x07)
              Own address type: Random (0x01)
              Peer address type: Public (0x00)
              Peer address: 00:00:00:00:00:00 (OUI 00-00-00)
              Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
              TX power: 127 dbm (0x7f)
              Primary PHY: LE 1M (0x01)
              Secondary max skip: 0x00
              Secondary PHY: LE 1M (0x01)
              SID: 0x00
              Scan request notifications: Disabled (0x00)
      > HCI Event: Command Complete (0x0e) plen 5
            LE Set Extended Advertising Parameters (0x08|0x0036) ncmd 1
              Status: Success (0x00)
              TX power (selected): 7 dbm (0x07)
      < HCI Command: LE Set Extended Advertising Enable (0x08|0x0039) plen 6
              Extended advertising: Enabled (0x01)
              Number of sets: 1 (0x01)
              Entry 0
                Handle: 0x00
                Duration: 0 ms (0x00)
                Max ext adv events: 0
      > HCI Event: Command Complete (0x0e) plen 4
            LE Set Extended Advertising Enable (0x08|0x0039) ncmd 2
              Status: Success (0x00)
      Signed-off-by: NJaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      de181e88
    • J
      Bluetooth: Set Scan PHYs based on selected PHYs by user · 45bdd86e
      Jaganath Kanakkassery 提交于
      Use the PHYs selected in Set Phy Configuration management command
      while scanning.
      
      < HCI Command: LE Set Extended Scan Parameters (0x08|0x0041) plen 13
              Own address type: Random (0x01)
              Filter policy: Accept all advertisement (0x00)
              PHYs: 0x05
              Entry 0: LE 1M
                Type: Active (0x01)
                Interval: 11.250 msec (0x0012)
                Window: 11.250 msec (0x0012)
              Entry 1: LE Coded
                Type: Active (0x01)
                Interval: 11.250 msec (0x0012)
                Window: 11.250 msec (0x0012)
      > HCI Event: Command Complete (0x0e) plen 4
            LE Set Extended Scan Parameters (0x08|0x0041) ncmd 1
              Status: Success (0x00)
      < HCI Command: LE Set Extended Scan Enable (0x08|0x0042) plen 6
              Extended scan: Enabled (0x01)
              Filter duplicates: Enabled (0x01)
              Duration: 0 msec (0x0000)
              Period: 0.00 sec (0x0000)
      > HCI Event: Command Complete (0x0e) plen 4
            LE Set Extended Scan Enable (0x08|0x0042) ncmd 2
              Status: Success (0x00)
      Signed-off-by: NJaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      45bdd86e
  22. 07 7月, 2018 2 次提交
    • J
      Bluetooth: Use extended scanning if controller supports · a2344b9e
      Jaganath Kanakkassery 提交于
      This implements Set extended scan param and set extended scan enable
      commands and use it for start LE scan based on controller support.
      
      The new features added in these commands are setting of new PHY for
      scanning and setting of scan duration. Both features are disabled
      for now, meaning only 1M PHY is set and scan duration is set to 0
      which means that scanning will be done untill scan disable is called.
      
      < HCI Command: LE Set Extended Scan Parameters (0x08|0x0041) plen 8
              Own address type: Random (0x01)
              Filter policy: Accept all advertisement (0x00)
              PHYs: 0x01
              Entry 0: LE 1M
                Type: Active (0x01)
                Interval: 11.250 msec (0x0012)
                Window: 11.250 msec (0x0012)
      > HCI Event: Command Complete (0x0e) plen 4
            LE Set Extended Scan Parameters (0x08|0x0041) ncmd 1
              Status: Success (0x00)
      < HCI Command: LE Set Extended Scan Enable (0x08|0x0042) plen 6
              Extended scan: Enabled (0x01)
              Filter duplicates: Enabled (0x01)
              Duration: 0 msec (0x0000)
              Period: 0.00 sec (0x0000)
      > HCI Event: Command Complete (0x0e) plen 4
            LE Set Extended Scan Enable (0x08|0x0042) ncmd 2
              Status: Success (0x00)
      Signed-off-by: NJaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      a2344b9e
    • J
      Bluetooth: Introduce helpers for LE set scan start and complete · 3baef810
      Jaganath Kanakkassery 提交于
      Introduce a helper hci_req_start_scan() which starts an LE
      scan and call it from passive_Scan() and active_scan().
      There is not functionality change in this patch.
      
      This is basically done to enable extended scanning if the
      controller supports which will be done in the subsequent
      patch
      Signed-off-by: NJaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      3baef810
  23. 18 5月, 2018 1 次提交
    • J
      Bluetooth: use wait_event API instead of open-coding it · 67d8cee4
      John Keeping 提交于
      I've seen timeout errors from HCI commands where it looks like
      schedule_timeout() has returned immediately; additional logging for the
      error case gives:
      
      	req_status=1 req_result=0 remaining=10000 jiffies
      
      so the device is still in state HCI_REQ_PEND and the value returned by
      schedule_timeout() is the same as the original timeout (HCI_INIT_TIMEOUT
      on a system with HZ=1000).
      
      Use wait_event_interruptible_timeout() instead of open-coding similar
      behaviour which is subject to the spurious failure described above.
      Signed-off-by: NJohn Keeping <john@metanate.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      67d8cee4
  24. 11 2月, 2018 1 次提交
  25. 13 12月, 2017 2 次提交