https://bugzilla.kernel.org/show_bug.cgi?id=213839 --- Comment #15 from Alan Stern (stern@xxxxxxxxxxxxxxxxxxx) --- Created attachment 300199 --> https://bugzilla.kernel.org/attachment.cgi?id=300199&action=edit Mark child resume requests in hub->event_bits, not hub->change_bits Congratulations on tracking this down. Later on I will send you a patch to disable autosuspend for these hubs, if it turns out to be needed. But for now, I'd like to track down the exact pathway for the problem, if you don't mind. Can you test the attached patch? It looks like there is a bug in the hub driver's resume handler. When a resuming hub sees that one of its downstream ports got a resume request from a child device, it sets a corresponding bit in the hub->change_bits variable. But this variable is meant for connection changes, not suspend/resume status changes; which explains why the child hub ends up getting reset. The bit should be set in the hub->event_bits variable instead. (If you read through port_event() and hub_event(), you'll see how the two variables are handled similarly but not exactly the same.) This bug wasn't noticed before because non-buggy devices don't change their descriptors, and hub_port_connect_change() is careful to check for cases where there wasn't a real connection change (i.e., device is still connected, port is still enabled, and device descriptors haven't changed). But your buggy hub does change its config descriptor and so it gets reset. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
