@@ -35,6 +35,12 @@
#define VERSION "1.0"
+/* Add module param to control whether the controller is powered down during
+ * suspend. Default is False.
+ */
+static bool power_down_suspend;
+module_param(power_down_suspend, bool, 0644);
+
static struct memory_type_mapping mem_type_mapping_tbl[] = {
{"ITCM", NULL, 0, 0xF0},
{"DTCM", NULL, 0, 0xF1},
@@ -1587,6 +1593,10 @@ static int btmrvl_sdio_probe(struct sdio_func *func,
goto disable_host_int;
}
+ if (power_down_suspend)
+ set_bit(HCI_QUIRK_POWER_DOWN_SYSTEM_SUSPEND,
+ &priv->btmrvl_dev.hcidev->quirks);
+
return 0;
disable_host_int:
After seeing a large number of suspend failures due to -EBUSY, the most common cause for failure seems to be the log snippet below: [ 4764.773873] Bluetooth: hci_cmd_timeout() hci0 command 0x0c14 tx timeout [ 4767.777897] Bluetooth: btmrvl_enable_hs() Host sleep enable command failed [ 4767.777920] Bluetooth: btmrvl_sdio_suspend() HS not actived, suspend failed! [ 4767.777946] dpm_run_callback(): pm_generic_suspend+0x0/0x48 returns -16 [ 4767.777963] call mmc2:0001:2+ returned -16 after 4882288 usecs Since the sleep command is timing out, this points to the firmware as the most likely source of the problem and we don't have a way to address the fix there (this is an old controller). So, to mitigate this issue, we can simply power down the Bluetooth controller when entering suspend and power it back up when exiting suspend. We control setting this quirk via a module parameter, power_down_suspend (which defaults to false). Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> --- drivers/bluetooth/btmrvl_sdio.c | 10 ++++++++++ 1 file changed, 10 insertions(+)