Note that it is perfectly normal for devices to be registered on a bus
without a driver. Perhaps the usbhid core doesn't expect this, though,
or perhaps it doesn't make sense for HID devices. Regardless, I don't
see how this could cause the problem.
Earlier, Bruno said that the hang occurs in hid_cancel_delayed_stuff(),
presumably during one of its cancel_work_sync() calls, and presumably
because the workqueue has been frozen. But as far as I can tell,
cancel_work_sync() should work just fine if the workqueue has been
frozen. Maybe this should be investigated more closely.
Bruno, can you confirm that the hang occurs during one of those
No, it's not one of the cancel_work_sync() that hangs but it's the
del_timer_sync() right before them that hangs!
(del_timer_sync() also hangs if I put it last, so the cancel_work_sync()
don't hang anything)
static void hid_cancel_delayed_stuff(struct usbhid_device *usbhid)
del_timer_sync(&usbhid->io_retry); /* this one never returns */
This very much reminds me the resume issue with the same keyboard on a
!CONFIG_SMP system back in February when the fix was to copy/move
usbhid->intf = intf; from usbhid_start() to usbhid_probe()!
Hopefully these are all those initializations that need to be taken
With this patch system now it passes "devices" level pm_test as well as
full suspend process, even multiple times in a row (though it's still
damn slow to resume IF no_console_suspend is passed to kernel - radeon
KMS?, but that's a new branch from start of this thread)
Reported-by: Bruno Prémont <email@example.com>
Tested-By: Bruno Prémont <firstname.lastname@example.org>
Now it can continue hunting the next issues preventing smooth S3