Comment 41 for bug 1856608

@dannf: Yes, this bug sure is a tricky one.

Most of these reports will be due to failing / faulty / non-spec complaint USB devices or cables, like the original reason for this bug being opened. Although, there have been some reports where user's systems do go back to working when they install my test kernel which reverts "usb: handle warm-reset port requests on hub resume".

When we wrote to the USB subsystem maintainer last year about the commit, they were pretty sure the commit worked as intended and that the USB device itself was malfunctioning. The commit is also in all of the upstream -stable kernels, in mainline, with no changes since when it was introduced. Which means that it works for the vast majority of users, and only fails for a very small minority of users.

We don't want to deviate from mainline by reverting patches we don't need to.

I suppose we could ask affected users for a debug trace of the USB subsystem during a boot, or plugging in a device which causes these messages, and start building a case against "usb: handle warm-reset port requests on hub resume", but at the same time, these errors could be due to failing hardware, and we don't have too many ways of figuring that out, especially if it happens to be a root hub that breaks.

It's tricky. We might have to read the USB spec again to see if "usb: handle warm-reset port requests on hub resume" is complaint, but I think it would be since it lasted in mainline this long.