Hello all, At Endless we are working on enabling a machine with a Qualcomm Atheros QCA9377 adapter, and are experiencing problems when scanning for BLE devices. btmon shows the ADV_IND and SCAN_RSP events, but no device found events are emitted by the kernel, so the user is not able to discover any BLE devices. Digging in the code and tracking HCI commands being sent to the adapter and their respective command complete events, I see the following: 1. All three HCI commands involved with starting a LE active scanning procedure (I'm using "btmgmt find -l"), LE_SET_RANDOM_ADDR, LE_SET_SCAN_PARAM and LE_SET_SCAN_ENABLE, are queued in hci_dev's skb and hci_cmd_work is scheduled and runs, sending LE_SET_RANDOM_ADDR to the controller. 2. A command complete (CC) event arrives for LE_SET_RANDOM_ADDR, is processed by hci_cc_le_set_random_addr, hci_sent_cmd_data runs with no errors and hci_cmd_work runs again, sending LE_SET_SCAN_PARAM to the controller. All good until this point. 3. Another CC event arrives for LE_SET_RANDOM_ADDR, but this time the CC opcode does not match the opcode from hdev->sent_cmd (the last HCI command sent to the controller) in hci_sent_cmd_data. Nothing is done so no real functional problem until this point. But continuing with the flow hci_cmd_work runs again and sends LE_SET_SCAN_ENABLE to the controller. 4. Now the CC event for LE_SET_SCAN_PARAM arrives, but since we already sent LE_SET_SCAN_ENABLE the CC opcode does not match the opcode from hdev->sent_cmd again in hci_sent_cmd_data, so hci_cc_le_set_scan_param never gets to set hdev->le_scan_type. At this point the controller is set to do an active scanning (CC reports success) but the kernel believes it is a passive scanning. 5. The CC event for LE_SET_SCAN_ENABLE arrives and is processed successfully, as no other HCI commands were sent in between. The scan procedure starts and ADV_IND and ADV_SCAN_RSP PDUs start to arrive, but no device found events are sent to userspace since the kernel believes this is a passive scanning procedure. This looks like a controller bug to me, but I may be missing something. Has this kind of problem been seen before? If it is indeed a controller bug, does any have contacts at Qualcomm-Atheros to report it? Feel free to put me in contact with them if that would help. Finally, if this is not fixable through a firmware update, does anyone have suggestions to work around it in the kernel? This was reproduced on a 4.20 kernel. Best regards, -- João Paulo Rechi Vita http://about.me/jprvita
