On 2018年11月27日 17:24, Johan Hedberg wrote:
Hi,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.
Ha, John, I'm pretty sure you do not debug these codes here by yourself, but one
point is right, the name has a little confusion.
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.
It has nothing to do with bt_dev_err, BT_DBG just mutes the issues. whether or not it will go wrong there if your driver level didn't take care of some events. Actually it's
OK to ignore it for most BT modules. Cheers, Zumeng
Johan
