On Fri, 8 Sept 2023 at 03:11, Daniel Ogorchock [off-list ref] 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.

quoted

+       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.

quoted

+
+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)

quoted

 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