If controller is reset during the discovery procedure, Start Discovery command stops working. This can be easily reproduced by running "hciconfig hci0 reset" while discovering devices, for instance. We should force discovery state to DISCOVERY_STOPPED in case we receive a reset command complete event. Otherwise we may stuck in one of the active discovery states (DISCOVERY_INQUIRY, DISCOVERY_LE_SCAN and DISCOVERY_RESOLVING) and subsequent Start Discovery commands will simply fail. Signed-off-by: Andre Guedes <andre.guedes@xxxxxxxxxxxxx> --- net/bluetooth/hci_event.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c index 179d127..6bd3bd2 100644 --- a/net/bluetooth/hci_event.c +++ b/net/bluetooth/hci_event.c @@ -198,6 +198,8 @@ static void hci_cc_reset(struct hci_dev *hdev, struct sk_buff *skb) /* Reset all flags, except persistent ones */ hdev->dev_flags &= BIT(HCI_MGMT) | BIT(HCI_SETUP) | BIT(HCI_AUTO_OFF) | BIT(HCI_LINK_KEYS) | BIT(HCI_DEBUG_KEYS); + + hdev->discovery.state = DISCOVERY_STOPPED; } static void hci_cc_write_local_name(struct hci_dev *hdev, struct sk_buff *skb) -- 1.7.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
