Hi Andre, On Thu, Mar 01, 2012, Andre Guedes wrote: > We are not supposed to force DISCOVERY_STOPPED in inquiry_cache_flush > because we may break the discovery state machine. For instance, > during interleaved discovery, when we are about to start inquiry, > the state machine forcibly goes to DISCOVERY_STOPPED while it > should stay in DISCOVERY_FINDING state. > > This problem results in unexpected behaviors such as sending two > mgmt_discovering events to userspace (when only one event is > expected) and Stop Discovery failures. > > Signed-off-by: Andre Guedes <andre.guedes@xxxxxxxxxxxxx> > --- > net/bluetooth/hci_core.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c > index d3ddc0b..661d65f 100644 > --- a/net/bluetooth/hci_core.c > +++ b/net/bluetooth/hci_core.c > @@ -413,7 +413,6 @@ static void inquiry_cache_flush(struct hci_dev *hdev) > > INIT_LIST_HEAD(&cache->unknown); > INIT_LIST_HEAD(&cache->resolve); > - cache->state = DISCOVERY_STOPPED; > } Nack. The reason why this was there is hci_dev_do_close() and hci_dev_reset() which call inquiry_cache_flush(). If the discovery state is not set correctly through these code paths you might get into a situation where you can't start discovery again after doing "hciconfig hci0 reset" or "hciconfig hci0 down" while discovery was active. So I agree that some fix is needed but you need to ensure that you don't break these use cases. Johan -- 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
