On Tue, Mar 8, 2016 at 10:14 AM, Mathias Nyman <mathias.nyman@xxxxxxxxx> wrote: > On 07.03.2016 22:13, Greg Kroah-Hartman wrote: >> >> On Mon, Mar 07, 2016 at 11:09:36AM -0800, Andy Lutomirski wrote: >>> >>> Quick ping here: this is still busted on 4.5-rc6. >>> >>> On Wed, Feb 17, 2016 at 9:40 AM, Andy Lutomirski <luto@xxxxxxxxxx> wrote: >>>> >>>> On Wed, Feb 17, 2016 at 8:18 AM, Mathias Nyman >>>> <mathias.nyman@xxxxxxxxxxxxxxx> wrote: >>>>> >>>>> On 17.02.2016 07:19, Andy Lutomirski wrote: >>>>>> >>>>>> >>>>>> On Tue, Feb 16, 2016 at 6:33 PM, Greg Kroah-Hartman >>>>>> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: >>>>>>> >>>>>>> >>>>>>> On Tue, Feb 16, 2016 at 10:01:13AM -0800, Andy Lutomirski wrote: >>>>>>>> >>>>>>>> >>>>>>>> I get some warnings at boot on all kernels I've tried. On 4.5-rc4, >>>>>>>> I >>>>>>>> see: >>>>>>>> >>>>> ... >>>>> >>>>>>>> [ 1.061036] hub 1-0:1.0: power on to power good time: 20ms >>>>>>>> [ 1.061109] hub 1-0:1.0: local power source is good >>>>>>>> [ 1.084337] usb usb1-port3: DeviceRemovable is changed to 1 >>>>>>>> according to platform information. >>>>>>>> [ 1.084339] usb usb1-port4: DeviceRemovable is changed to 1 >>>>>>>> according to platform information. >>>>>>>> [ 1.084341] usb usb1-port5: DeviceRemovable is changed to 1 >>>>>>>> according to platform information. >>>>> >>>>> >>>>> ... >>>>>>>> >>>>>>>> >>>>>>>> [ 1.085684] usb usb2-port1: peered to usb1-port1 >>>>>>>> [ 1.086356] usb usb2-port2: peered to usb1-port2 >>>>>>>> [ 1.087004] usb usb2-port3: peered to usb1-port6 >>>>>>>> [ 1.087713] usb: failed to peer usb2-port4 and usb1-port6 by >>>>>>>> location (usb2-port4:none) (usb1-port6:usb2-port3) >>>>>>>> [ 1.087715] usb usb2-port4: failed to peer to usb1-port6 (-16) >>>>>>>> [ 1.087716] usb: port power management may be unreliable >>>>>>>> [ 1.088377] usb: failed to peer usb2-port5 and usb1-port6 by >>>>>>>> location (usb2-port5:none) (usb1-port6:usb2-port3) >>>>>>>> [ 1.088379] usb usb2-port5: failed to peer to usb1-port6 (-16) >>>>>>>> [ 1.089017] usb: failed to peer usb2-port6 and usb1-port6 by >>>>>>>> location (usb2-port6:none) (usb1-port6:usb2-port3) >>>>>>>> [ 1.089018] usb usb2-port6: failed to peer to usb1-port6 (-16) >>>>>>> >>>>>>> >>>>>>> >>>>>>> Other than your internal hub not liking to be a peer (which seems >>>>>>> like a >>>>>>> BIOS/ACPI issue, right Mathias), I don't see an error here. Are >>>>>>> things >>>>>>> working properly? >>>> >>>> >>>> No, actually. >>>> >>>> The USB 3.0 ports seem to work fine, although I haven't tried >>>> suspending with a device inserted. >>>> >>>> The USB Type C port is presently screwed up. I have a Realtek USB C >>>> to Ethernet adapter. If I plug it in, nothing shows up in the logs at >>>> all. If I suspend while it's plugged in, the screen turns off and the >>>> system freezes hard without going to sleep. >>>> >>>> The Realtek adapter used to work, but that was on an older kernel >>>> (4.3?) and a different BIOS version. >>>> >>>>> >>>>> >>>>> Probably. >>>>> The "by location" message in the log reveals that the peering >>>>> is based on ACPI DSDT table _PLD entries (Physical Device Location). >>>>> >>>>> usb2 ports 3-6 are all peered with usb1 port6. >>>>> First two ports appear to be sane (usb1_port1 <->usb2_port1) >>>>> >>>>> How many physical ports does the DELL XPS have visible and connectable? >>>> >>>> >>>> There are: >>>> >>>> - Two Super Speed ports. (If I'm understanding correctly, one is 1-1 >>>> and one is 1-2.) >>>> - One USB Type C port (Alpine Ridge) >>>> - Two internal M.2 ports >>>> >>>> One of the M.2 ports has an Intel 7265 plugged in, and that's the >>>> Bluetooth device. The other one has an nvme device plugged in, and I >>>> have no idea whether USB is wired up. >>>> >>>> The Intel 7265 is "removable" in the sense that I personally inserted >>>> it into the port (with the power off, of course). >>>> >>>>> >>>>> The ACPI DSDt _UPC entry describes if a port is hardwired or hotplug, >>>>> and >>>>> the >>>>> hub descriptor DeviceRemovable field are also involved in all this. >>>>> The log also shows changing the built in bluetooth and webcam to >>>>> removable >>>>> which >>>>> is a bit suspicious >>>>> >>>>> >>>>>> >>>>>> >>>>>> I think so, but I haven't tested with a USB device plugged in across >>>>>> suspend/resume. I do get this on resume, though: >>>>>> >>>>>> [ +0.008245] ACPI: Waking up from system sleep state S3 >>>>>> [ +0.137335] xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI >>>>>> [ +0.000117] PM: noirq resume of devices complete after 12.890 msecs >>>>>> [ +0.011969] PM: early resume of devices complete after 11.890 msecs >>>>>> [ +0.000345] usb usb1: root hub lost power or was reset >>>>>> [ +0.000005] usb usb2: root hub lost power or was reset >>>>>> [ +0.005946] rtc_cmos 00:01: System wakeup disabled by ACPI >>>>>> [ +0.364455] usb 1-3: reset full-speed USB device number 2 using >>>>>> xhci_hcd >>>>>> [ +0.318243] usb 1-5: reset high-speed USB device number 3 using >>>>>> xhci_hcd >>>>>> [ +0.208028] PM: resume of devices complete after 896.974 msecs >>>>>> [ +0.000109] usb 1-3:1.0: rebind failed: -517 >>>>>> [ +0.000007] usb 1-3:1.1: rebind failed: -517 >>>>> >>>>> >>>>> >>>>> was usb 1-3 the bluetooth device? >>>> >>>> >>>> [ +0.044127] usb 1-3: new full-speed USB device number 2 using xhci_hcd >>>> [ +0.166395] usb 1-3: New USB device found, idVendor=8087, >>>> idProduct=0a2a >>>> [ +0.000009] usb 1-3: New USB device strings: Mfr=0, Product=0, >>>> SerialNumber=0 >>>> >>>> So, yes, I think so. Right now, 1-3:1.0 and 1-3:1.1 are both bound by >>>> btusb. >>>> >>>> I attached the DSDT. >>>> >>>> I have the ACPI debugger working, so I can dump things if that would be >>>> helpful. >>>> >>>> --Andy >>> >>> >> >> Mathias, any ideas? >> > > Regarding the type-c issue I think that the Dell XPS 13 9350 has a separate > Alpine Ridge solution. > > The only Alpine Ridge implementation I have seen had two separate xHCI > controllers. > One generic for all "normal" ports, and a separate one for the Alpine Ridge > type-c port. > > The Alpine ridge xHCI controller one was hotpluggable, xHCI magically > appeared on the > PCI bus when the first USB device was connected to the type-C port. > It also disappeared after the last type-C USB device was disconnected. > It just worked so haven't dealt with the firmware in this case That seems considerably more complicated than just having the thing exist on the bus all the time and instead enumerate a new device when something gets plugged in. > > Only thing that comes to mind is that kernel needed HOTPLUG_PCI and > HOTPLUG_PCI_ACPI > enabled to work. I have those enabled. > > I'm not familiar at all with how DELL has implemented this > Does a second xHCI controller appear when using the type-C port? with any > type-c usb device? No. Instead, ACPI blows up due to the aforementioned DSDT bug. I assume that Windows does something slightly different during boot so that the bug doesn't trigger. I need to figure out how to wrangle dracut to insert the custom method early enough in boot to test this. I'm guessing that, if the _Q66 handler didn't hang, it would do something that would make the port work. Or Dell could just send me a fixed BIOS :) --Andy -- 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
