linux-kernel - Re: [PATCH v2 RESEND] HID: nintendo: reinitialize USB Pro Controller after resuming from suspend

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: <CAKst+mB9nm1wiPEJu1COwK422d+wbnW15Uc=s2QYD-QaP=xdGA@mail.gmail.com>
Date:   Sun, 10 Sep 2023 12:33:08 +0200
From:   Martino Fontana <tinozzo123@...il.com>
To:     Daniel Ogorchock <djogorchock@...il.com>
Cc:     jikos@...nel.org, benjamin.tissoires@...hat.com,
        linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 RESEND] HID: nintendo: reinitialize USB Pro Controller
 after resuming from suspend

On Fri, 8 Sept 2023 at 03:11, Daniel Ogorchock <djogorchock@...il.com> wrote:
>
> Have you tested how this behaves for bluetooth controllers? Does the
> pm resume hook always result in error logs for bluetooth controllers,
> or has the kernel already removed the device before resume?

Tested on a Bluetooth connection, it behaves like it did before: the
controller disconnects as the computer sleeps, and you can have
to reconnect it by pressing a button on the controller.

I also don't see any log from that wasn't there before on journalctl.

> > +       mutex_unlock(&ctlr->output_mutex);
> > +       return 0;
>
> If desired, you could remove the above two lines and allow flow to
> continue through err_mutex even in the success case.
>
> > +
> > +err_mutex:
> > +       mutex_unlock(&ctlr->output_mutex);
> > +       return ret;
> > +}
> > +

Do I make a patch v3 for that, or is that not necessary?
(Asking because this is my first Linux kernel patch)

> >  static const struct hid_device_id nintendo_hid_devices[] = {
> >         { HID_USB_DEVICE(USB_VENDOR_ID_NINTENDO,
> >                          USB_DEVICE_ID_NINTENDO_PROCON) },
> > @@ -2404,6 +2434,10 @@ static struct hid_driver nintendo_hid_driver = {
> >         .probe          = nintendo_hid_probe,
> >         .remove         = nintendo_hid_remove,
> >         .raw_event      = nintendo_hid_event,
> > +
> > +#ifdef CONFIG_PM
> > +       .resume         = nintendo_hid_resume,
> > +#endif
>
> Something else we should do is add a suspend hook to power off the
> bluetooth-connected controllers. As of now, they remain powered on
> during suspend.

No, they power off when you suspend the computer. If you press a button,
the controller will attempt to pair, just like if you disconnected it manually.
As I said before, Bluetooth behavior isn't changed.

Regards,
Martino