linux-kernel - Re: [PATCH] Bluetooth: btusb: Introduce generic USB reset

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] [day] [month] [year] [list]
Message-ID: <CAJQfnxF9iMeO+CR3p5hbVP=2wDMzp-6DgOCzyMNXPYH_8gYXuw@mail.gmail.com>
Date:   Wed, 5 Oct 2022 14:43:51 +0800
From:   Archie Pusaka <apusaka@...gle.com>
To:     Luiz Augusto von Dentz <luiz.dentz@...il.com>
Cc:     linux-bluetooth <linux-bluetooth@...r.kernel.org>,
        Marcel Holtmann <marcel@...tmann.org>,
        CrosBT Upstreaming <chromeos-bluetooth-upstreaming@...omium.org>,
        Archie Pusaka <apusaka@...omium.org>,
        Abhishek Pandit-Subedi <abhishekpandit@...gle.com>,
        Ying Hsu <yinghsu@...omium.org>,
        Johan Hedberg <johan.hedberg@...il.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Bluetooth: btusb: Introduce generic USB reset

Hi Luiz,

On Wed, 5 Oct 2022 at 04:53, Luiz Augusto von Dentz
<luiz.dentz@...il.com> wrote:
>
> Hi Archie,
>
> On Tue, Oct 4, 2022 at 1:33 AM Archie Pusaka <apusaka@...gle.com> wrote:
> >
> > From: Archie Pusaka <apusaka@...omium.org>
> >
> > On cmd_timeout and there is no reset_gpio, reset the USB port as a
> > last resort.
> >
> > Signed-off-by: Archie Pusaka <apusaka@...omium.org>
> > Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@...gle.com>
> > Reviewed-by: Ying Hsu <yinghsu@...omium.org>
> >
> > ---
> >
> >  drivers/bluetooth/btusb.c | 26 ++++++++++++++++----------
> >  1 file changed, 16 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> > index 271963805a38..11040124ef79 100644
> > --- a/drivers/bluetooth/btusb.c
> > +++ b/drivers/bluetooth/btusb.c
> > @@ -696,6 +696,19 @@ struct btusb_data {
> >         unsigned cmd_timeout_cnt;
> >  };
> >
> > +static void generic_usb_reset(struct hci_dev *hdev, struct btusb_data *data)
> > +{
> > +       int err;
> > +
> > +       bt_dev_err(hdev, "Resetting usb device.");
> > +       /* This is not an unbalanced PM reference since the device will reset */
> > +       err = usb_autopm_get_interface(data->intf);
> > +       if (!err)
> > +               usb_queue_reset_device(data->intf);
> > +       else
> > +               bt_dev_err(hdev, "Failed usb_autopm_get_interface: %d", err);
>
> Lets just have one line printed if it fails:
>
> err = usb_autopm_get_interface(data->intf);
> if (err) {
>         bt_dev_err(hdev, "Failed usb_autopm_get_interface: %d", err);
>         return;
> }
>
> bt_dev_err(hdev, "Resetting usb device.");
> usb_queue_reset_device(data->intf);
>
OK, will update

> > +}
> > +
> >  static void btusb_intel_cmd_timeout(struct hci_dev *hdev)
> >  {
> >         struct btusb_data *data = hci_get_drvdata(hdev);
> > @@ -705,7 +718,7 @@ static void btusb_intel_cmd_timeout(struct hci_dev *hdev)
> >                 return;
> >
> >         if (!reset_gpio) {
> > -               bt_dev_err(hdev, "No way to reset. Ignoring and continuing");
> > +               generic_usb_reset(hdev, data);
>
> Lets call it btusb_reset since this is specific for the data->intf,
> btw is this safe, or perhaps we want to refactor this to have it
> callback based so each vendor can add it own specific hdev->reset
> callback hardware reset with btusb_reset serving as default callback?

OK. I think this is safe at least for now, since resetting btusb is
probably better than just giving up doing nothing.
But I can add hdev->reset if that is desirable.

> Also the logic of btusb_intel_cmd_timeout should probably be put
> inside btintel.c and I don't think we need the gpio_desc reference to
> be inside the btusb_data since we can call gpiod_get_optional during
> the reset phase and immediately do gpiod_put after done using it.
>
I am not familiar with this part.
Perhaps it's better for this to be managed by another patch, since it
is not the focus of this patch?

> >                 return;
> >         }
> >
> > @@ -736,7 +749,7 @@ static void btusb_rtl_cmd_timeout(struct hci_dev *hdev)
> >                 return;
> >
> >         if (!reset_gpio) {
> > -               bt_dev_err(hdev, "No gpio to reset Realtek device, ignoring");
> > +               generic_usb_reset(hdev, data);
> >                 return;
> >         }
> >
> > @@ -761,7 +774,6 @@ static void btusb_qca_cmd_timeout(struct hci_dev *hdev)
> >  {
> >         struct btusb_data *data = hci_get_drvdata(hdev);
> >         struct gpio_desc *reset_gpio = data->reset_gpio;
> > -       int err;
> >
> >         if (++data->cmd_timeout_cnt < 5)
> >                 return;
> > @@ -787,13 +799,7 @@ static void btusb_qca_cmd_timeout(struct hci_dev *hdev)
> >                 return;
> >         }
> >
> > -       bt_dev_err(hdev, "Multiple cmd timeouts seen. Resetting usb device.");
> > -       /* This is not an unbalanced PM reference since the device will reset */
> > -       err = usb_autopm_get_interface(data->intf);
> > -       if (!err)
> > -               usb_queue_reset_device(data->intf);
> > -       else
> > -               bt_dev_err(hdev, "Failed usb_autopm_get_interface with %d", err);
> > +       generic_usb_reset(hdev, data);
> >  }
> >
> >  static inline void btusb_free_frags(struct btusb_data *data)
> > --
> > 2.38.0.rc1.362.ged0d419d3c-goog
> >
>
>
> --
> Luiz Augusto von Dentz

Cheers,
Archie