linux-kernel - Re: [PATCH] Bluetooth: btusb: Avoid unnecessary reset upon system resume

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 23 Sep 2020 13:41:11 -0700
From:   Abhishek Pandit-Subedi <abhishekpandit@...omium.org>
To:     Kai-Heng Feng <kai.heng.feng@...onical.com>
Cc:     Marcel Holtmann <marcel@...tmann.org>,
        Johan Hedberg <johan.hedberg@...il.com>,
        Alex Lu <alex_lu@...lsil.com.cn>,
        "open list:BLUETOOTH DRIVERS" <linux-bluetooth@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Bluetooth: btusb: Avoid unnecessary reset upon system resume

Hi Kai-Heng,

Which Realtek controller is this on?

Specifically for RTL8822CE, we tested without reset_resume being set
and that was causing the controller being reset without bluez ever
learning about it (resulting in devices being unusable without
toggling the BT power).
If the firmware doesn't cut off power during suspend, maybe you
shouldn't set the BTUSB_WAKEUP_DISABLE flag for that controller.

I would prefer this doesn't get accepted in its current state.

Abhishek

On Wed, Sep 23, 2020 at 10:56 AM Kai-Heng Feng
<kai.heng.feng@...onical.com> wrote:
>
> Realtek bluetooth controller may fail to work after system sleep:
> [ 1272.707670] Bluetooth: hci0: command 0x1001 tx timeout
> [ 1280.835712] Bluetooth: hci0: RTL: HCI_OP_READ_LOCAL_VERSION failed (-110)
>
> If platform firmware doesn't cut power off during suspend, the firmware
> is considered retained in controller but the driver is still asking USB
> core to perform a reset-resume. This can make bluetooth controller
> unusable.
>
> So avoid unnecessary reset to resolve the issue.
>
> For devices that really lose power during suspend, USB core will detect
> and handle reset-resume correctly.
>
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@...onical.com>
> ---
>  drivers/bluetooth/btusb.c | 8 +++-----
>  1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 8d2608ddfd08..de86ef4388f9 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -4255,17 +4255,15 @@ static int btusb_suspend(struct usb_interface *intf, pm_message_t message)
>                 enable_irq(data->oob_wake_irq);
>         }
>
> -       /* For global suspend, Realtek devices lose the loaded fw
> -        * in them. But for autosuspend, firmware should remain.
> -        * Actually, it depends on whether the usb host sends
> +       /* For global suspend, Realtek devices lose the loaded fw in them if
> +        * platform firmware cut power off. But for autosuspend, firmware
> +        * should remain.  Actually, it depends on whether the usb host sends
>          * set feature (enable wakeup) or not.
>          */
>         if (test_bit(BTUSB_WAKEUP_DISABLE, &data->flags)) {
>                 if (PMSG_IS_AUTO(message) &&
>                     device_can_wakeup(&data->udev->dev))
>                         data->udev->do_remote_wakeup = 1;
> -               else if (!PMSG_IS_AUTO(message))
> -                       data->udev->reset_resume = 1;
>         }
>
>         return 0;
> --
> 2.17.1
>