Hi Marcel, On Wed, Jan 28, 2015, Marcel Holtmann wrote: > When loading the Intel firmware it can happen that the firmware loading > complete vendor event arrives before the command complete event for the > last firmware fragment. > > < HCI Command: Vendor (0x3f|0x0009) plen 7 > 01 02 fc 03 00 00 00 > > HCI Event: Vendor (0xff) plen 5 > 06 00 00 00 00 > > HCI Event: Command Complete (0x0e) plen 4 > Vendor (0x3f|0x0009) ncmd 31 > Status: Success (0x00) > > This is mainly caused by the fact that the vendor command and its > command complete event are transported over the bulk endpoints. The > firmware loading complete event however is send over the interrupt > endpoint. So with just bad timing one event arrives before the other. > > Currently the code does not account for it. There are precautions for > receiving firmware loading complete event quickly, but not for receiving > it before the command complete. > > Introduce an extra flag that tracks when the firmware sending has > completed from the driver point of view and track the completion of > the firmware loading procedure with a different flag. That way the > wakeup can be handled properly. > > Signed-off-by: Marcel Holtmann <marcel@xxxxxxxxxxxx> > --- > drivers/bluetooth/btusb.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) This made firmware loading again stable for me so I went ahead and applied the patch to bluetooth-next. Thanks. 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
