Hi Andiry,
I've been running into an issue with an xHCI host that's very strict
about the rule in the xHCI spec that a port status change event is not
generated if a change bit hasn't been cleared by software. What I think
are bugs in the xHCI driver are causing future port status changes to be
lost.
I'm having issues after the resume of a USB 2.0 hub, and I thought I'd
ping you on them, since you wrote the device suspend/resume code.
The USB 2.0 roothub port state diagram in Figure 34 in the xHCI spec
shows that PLC (port link state change) is set on the transition from U3
to resume. The port status change event handler even checks for that
bit being set for both USB 2.0 and USB 3.0 devices:
static void handle_port_status(struct xhci_hcd *xhci,
union xhci_trb *event)
...
if ((temp & PORT_PLC) && (temp & PORT_PLS_MASK) == XDEV_RESUME) {
xhci_dbg(xhci, "port resume event for port %d\n", port_id);
However, before your USB 2.0 LPM changes were merged for 3.2, there was
no where in the code where the PLC bit was cleared for USB 2.0 devices,
AFAICT.
So on this very strict host controller, here's what would happen:
1. USB 2.0 hub is suspended.
2. New USB device plugged into the hub. Hub resumes, and the PLC bit is
set and never cleared.
3. USB device and hub are eventually both suspended.
4. User unplugs the USB device from the hub.
5. Absolutely nothing happens.
At this point, the USB 2.0 hub is trying to signal a resume, since the
wake-on-disconnect bits have been set for that child port. However, PLC
bit for the hub's rootport is still set from the first hub resume
sequence, so the xHCI host controller never interrupts with a new port
status change event, and the disconnect is never noticed. The user can
"manually" make the system notice the disconnect by running an older
version of lsusb, which will resume the roothub in order to fetch the
device descriptors.
This bug doesn't show up on all host controllers (not NEC, in
particular), so apparently some hosts aren't as strict about the
edge-triggered port status change event generation.
In any case, can you look over the original device suspend/resume
patches and let me know if there's a reason why you didn't clear PLC?
If it's just a bug, I'll send off these commits to the stable tree:
6fd4562 xHCI: Clear PLC for USB2 root hub ports
d2f52c9 xHCI: test and clear RWC bit
Thanks,
Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
