Bug 202095 - Default runtime PM for Alpine Ridge USB Controller breaks usage on Asus Maximus VIII Impact Motherboard
Summary: Default runtime PM for Alpine Ridge USB Controller breaks usage on Asus Maxim...
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: USB (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: Greg Kroah-Hartman
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-30 01:29 UTC by Philip Langdale
Modified: 2018-12-30 08:26 UTC (History)
1 user (show)

See Also:
Kernel Version: 4.20
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
Patch to skip quirk based on subsystem match (1.64 KB, patch)
2018-12-30 01:53 UTC, Philip Langdale
Details | Diff

Description Philip Langdale 2018-12-30 01:29:16 UTC
In this change: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2815ef7fe4d43072b9eda448d04fbc184f2aa513

Runtime PM was turned on by default for the XHCI controller that's part of the Alpine Ridge thunderbolt controller.

The ASUS Maximus VIII Impact motherboard, which I have, is a funny beast, which uses an Alpine Ridge (0x1578 specifically) chip but with Thunderbolt disabled, and running in some mode where it only does USB 3.1 and nothing else. The USB controller is always visible and none of the Thunderbolt control mechanisms are exposed, I believe (but I've not looked through the ACPI, and probably wouldn't recognise anything even if I did). (They did this weird configuration because apparently they couldn't run the wiring in a thunderbolt compliant way.)

After this change is active, the USB controller appears as normal and the root hub is detected but if I plug a USB device in, nothing gets detected. If I have a device plugged in at boot, that devices is detected but once unplugged, it can't be plugged in again. So whatever mechanism is being used to detect a plugged in device is going to sleep and not waking up or otherwise working.

I've confirmed that manually disabling runtime PM makes things work again.

I've put together a trivial patch to skip applying the new quirk if the subsystem vendor/device IDs are detected on the USB controller (although note that the values appear made up (subsystem_vendor: 0x2222, subsystem_device: 0x1111).

I'll attach it shortly, after I do a full test.
Comment 1 Philip Langdale 2018-12-30 01:53:01 UTC
Created attachment 280193 [details]
Patch to skip quirk based on subsystem match
Comment 2 Greg Kroah-Hartman 2018-12-30 08:26:50 UTC
On Sun, Dec 30, 2018 at 01:29:16AM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=202095
> 
>             Bug ID: 202095
>            Summary: Default runtime PM for Alpine Ridge USB Controller
>                     breaks usage on Asus Maximus VIII Impact Motherboard
>            Product: Drivers
>            Version: 2.5
>     Kernel Version: 4.20

All USB bugs should be sent to the linux-usb@vger.kernel.org mailing
list, and not entered into bugzilla.  Please bring this issue up there,
if it is still a problem in the latest kernel release.

Note You need to log in before you can comment on or make changes to this bug.