On 2018年11月27日 17:34, Johan Hedberg wrote:
On 27 Nov 2018, at 11.24, Johan Hedberg <johan.hedberg@xxxxxxxxx> wrote:
On 15 Nov 2018, at 3.31, Zumeng Chen <zumeng.chen@xxxxxxxxx> wrote:
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -5217,7 +5217,8 @@ static bool hci_get_cmd_complete(struct hci_dev *hdev, u16 opcode,
return true;
}
- if (hdr->evt != HCI_EV_CMD_COMPLETE) {
+ if (!(hdr->evt == HCI_EV_CMD_COMPLETE ||
+ hdr->evt == HCI_EV_CMD_STATUS)) {
bt_dev_err(hdev, "last event is not cmd complete (0x%2.2x)",
hdr->evt);
return false;
This is not correct. The purpose of this function is to retrieve the command complete parameters, or the parameters of a specific event if the sending code indicated it (it didn’t in this case). Since the event was not command complete the right behaviour for this function is to fail, i.e. return false. The only issue here is the bt_dev_err, which should probably be downgraded to a BT_DBG. In fact, that’s what it used to be in the past - I’m not sure why it was changed to bt_dev_err.
The one improvement I’d make however, is to silently return from the function in case of a Command Status event, since that just means that the request is complete, however there are no extra parameters to be retrieved. I’ll be sending a patch for that in a moment.
There is a related kernel as shown in the below list
https://bugzilla.kernel.org/show_bug.cgi?id=198699
I didn't think my patch is to fix this one because I think we need to
sort out
the whole logic of CMD_COMPLETE. But my patch is good to fix the issue
described by subject.
Cheers,
Zumeng
Johan
