Issues with DSDT bios issues "Dell Bios guys have a look"

On Mon, Mar 7, 2016 at 12:13 PM, 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 
    
      wrote:
    
>
   > > On Wed, Feb 17, 2016 at 8:18 AM, Mathias Nyman
>
   > > 
    
      wrote:
    
>
   > >> On 17.02.2016 07:19, Andy Lutomirski wrote:
>
   > >>>
>
   > >>> On Tue, Feb 16, 2016 at 6:33 PM, Greg Kroah-Hartman
>
   > >>> 
    
      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?
>
   

I'm adding a couple Dell people.

Hi, Dell people-

Your latest DSDT has this blatantly buggy method:

            Method (_Q66, 0, NotSerialized)  // _Qxx: EC Query
            {
                Acquire (PATM, 0x0064)
                If ((ECRD != One))
                {
                    Return (Zero)
                }

                NEVT ()
                Release (PATM)
                Return (Zero)
            }

At some point during boot (presumably), this runs with ECRD == 0,
causing PATM to be acquired and never released.  Later on, something
involved in USB-C hotplug (I think -- I can occasionally trigger
errors during hotplug) breaks when it can't acquire PATM.

Could you ask your BIOS team to please add the obviously missing Release (PATM)?

I don't know if fixing this bug will solve all the USB-C issues, but
it seems unlikely to hurt.  I'm going to try to get it to work with a
custom method, but I may or may not succeed.

--Andy