[Bug 213839] XHCI 7 port usb hub does not work correctly

[bugzilla-daemon@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=213839

--- Comment #15 from Alan Stern (stern@rowland.harvard.edu) ---
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.