Skip to content

Commit 8ae22de

Browse files
diandersVudentz
authored andcommitted
Bluetooth: qca: If memdump doesn't work, re-enable IBS
On systems in the field, we are seeing this sometimes in the kernel logs: Bluetooth: qca_controller_memdump() hci0: hci_devcd_init Return:-95 This means that _something_ decided that it wanted to get a memdump but then hci_devcd_init() returned -EOPNOTSUPP (AKA -95). The cleanup code in qca_controller_memdump() when we get back an error from hci_devcd_init() undoes most things but forgets to clear QCA_IBS_DISABLED. One side effect of this is that, during the next suspend, qca_suspend() will always get a timeout. Let's fix it so that we clear the bit. Fixes: 06d3fdf ("Bluetooth: hci_qca: Add qcom devcoredump support") Reviewed-by: Guenter Roeck <groeck@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
1 parent fe1910f commit 8ae22de

1 file changed

Lines changed: 1 addition & 0 deletions

File tree

drivers/bluetooth/hci_qca.c

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1091,6 +1091,7 @@ static void qca_controller_memdump(struct work_struct *work)
10911091
qca->memdump_state = QCA_MEMDUMP_COLLECTED;
10921092
cancel_delayed_work(&qca->ctrl_memdump_timeout);
10931093
clear_bit(QCA_MEMDUMP_COLLECTION, &qca->flags);
1094+
clear_bit(QCA_IBS_DISABLED, &qca->flags);
10941095
mutex_unlock(&qca->hci_memdump_lock);
10951096
return;
10961097
}

0 commit comments

Comments
 (0)