| Message ID | 20240821154339.REPOST.1.Ia769fe5fbeaa6aca2edfb01b82eb7df0c6955459@changeid (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 61bea6923172a4a9d279f3032abb1eb283ab23c0 |
| Headers | show |
| Series | [REPOST] Bluetooth: qca: If memdump doesn't work, re-enable IBS | expand |
| Context | Check | Description |
|---|---|---|
| tedd_an/pre-ci_am | success | Success |
| tedd_an/CheckPatch | success | CheckPatch PASS |
| tedd_an/GitLint | success | Gitlint PASS |
| tedd_an/SubjectPrefix | success | Gitlint PASS |
| tedd_an/BuildKernel | success | BuildKernel PASS |
| tedd_an/CheckAllWarning | success | CheckAllWarning PASS |
| tedd_an/CheckSparse | success | CheckSparse PASS |
Hello: This patch was applied to bluetooth/bluetooth-next.git (master) by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>: On Wed, 21 Aug 2024 15:43:40 -0700 you wrote: > 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. > > [...] Here is the summary with links: - [REPOST] Bluetooth: qca: If memdump doesn't work, re-enable IBS https://git.kernel.org/bluetooth/bluetooth-next/c/61bea6923172 You are awesome, thank you!
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index 45adc1560d94..efce3846d5fc 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -1091,6 +1091,7 @@ static void qca_controller_memdump(struct work_struct *work) qca->memdump_state = QCA_MEMDUMP_COLLECTED; cancel_delayed_work(&qca->ctrl_memdump_timeout); clear_bit(QCA_MEMDUMP_COLLECTION, &qca->flags); + clear_bit(QCA_IBS_DISABLED, &qca->flags); mutex_unlock(&qca->hci_memdump_lock); return; }
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: 06d3fdfcdf5c ("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> --- drivers/bluetooth/hci_qca.c | 1 + 1 file changed, 1 insertion(+)