Comment 4 for bug 1049623

Sorry, make that "reset_resume error 1" (+1, not -1). After reviewing the HID/USBHID kernel code, it seems that reset_resume is a special method called only on quirky USB devices. The method isn't defined in the hid_logitech driver, and indeed our receiver (ID 046d:c517) isn't listed for USB_QUIRK_RESET_RESUME in drivers/usb/core/quirks.c. I'm not sure how it's getting designated as such.

Instead we're getting the "1" from hid_post_reset, either because it couldn't read the report descriptor or because that had changed. I note that the hid_logitech driver has a routine for "fixing up" report descriptors for keyboards. According to the dmesg output (both mine and OP's), this is being done after initial boot and unplug/replug, but not after resume. That may be leading to the changed descriptor that would give "reset_resume error 1". Strange, though, that the keyboard descriptor would be at issue and it's the mouse, instead, that freezes.

I'm not sure if the receiver needs to be taken off the quirky list somehow or if a reset_resume method needs to be written for it. The only change to the hid_logitech driver between 3.2.0 and 3.5.0 was to adjust the way it stores its own quirks list (not related to the above), which does control whether or not the "fixing up" occurs. Based on my old kernel logs, though, the "fixing up" was happening for me on a 3.2 kernel as well without any issue.