On Fri, 8 Sept 2023 at 03:11, Daniel Ogorchock <djogorchock@xxxxxxxxx> 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
