> -----Original Message----- > From: Heikki Krogerus [mailto:heikki.krogerus@xxxxxxxxxxxxxxx] > Sent: Thursday, May 17, 2018 4:00 AM > To: Limonciello, Mario > Cc: greg@xxxxxxxxx; pmenzel+linux-usb@xxxxxxxxxxxxx; linux- > usb@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx > Subject: Re: `ucsi_acpi: probe of USBC000:00 failed with error -12` on Dell XPS 13 > 9370 > > Hi, > > On Wed, May 16, 2018 at 04:13:31PM +0000, Mario.Limonciello@xxxxxxxx wrote: > > > > > > > -----Original Message----- > > > From: Heikki Krogerus [mailto:heikki.krogerus@xxxxxxxxxxxxxxx] > > > Sent: Wednesday, May 16, 2018 6:58 AM > > > To: Greg KH; Paul Menzel > > > Cc: linux-usb@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Limonciello, Mario > > > Subject: Re: `ucsi_acpi: probe of USBC000:00 failed with error -12` on Dell XPS 13 > > > 9370 > > > > > > Hi, > > > > > > On Wed, May 16, 2018 at 10:02:26AM +0200, Greg KH wrote: > > > > On Tue, May 15, 2018 at 06:47:37PM +0200, Paul Menzel wrote: > > > > > Dear Greg, > > > > > > > > > > > > > > > As always, thank you for the prompt response. > > > > > > > > > > > > > > > On 05/15/18 18:00, Greg KH wrote: > > > > > > On Tue, May 15, 2018 at 04:34:03PM +0200, Paul Menzel wrote: > > > > > > > > > > > > Linux 4.17-rc5 shows the error below on the Dell XPS 13 9370 with Debian > > > > > > > Sid/unstable. > > > > > > > > > > > > > > ``` > > > > > > > [???] > > > > > > > [ 0.440240] usb: port power management may be unreliable > > > > > > > [ 0.441358] usbcore: registered new interface driver usb-storage > > > > > > > [ 0.441367] usbcore: registered new interface driver usbserial_generic > > > > > > > [ 0.441369] usbserial: USB Serial support registered for generic > > > > > > > [ 0.441383] ioremap error for 0x3f799000-0x3f79a000, requested 0x2, > got > > > > > > > 0x0 > > > > > > > [ 0.441518] ucsi_acpi: probe of USBC000:00 failed with error -12 > > > > > > > [???] > > > > > > > ``` > > > > > > > > > > > > > > 1. Are the ioremap and ucsi_acpi error related or is a separate report > > > > > > > needed? > > > > > > > > > > > > The ioremap error is what causes ucsi_acpi to fail the probe call (-12 > > > > > > is "out of memory".) > > > > > > > > > > > > > 2. Do you know the reason for the ucsi_acpi error? > > > > > > > > > > > > the call to ioremap failed. > > > > > > > > > > > > Does this device really have a working typec connector? > > > > > > > > > > Just to avoid misunderstandings, no device was connected to the laptop > > > > > during my test. > > > > > > > > > > But, from other boots, the Dell docking station TB16 kind of works with it, > > > > > so I???d say the USB Type-C connector is working. > > > > > > > > Ok, good, this might just be the acpi tables not set up properly for > > > > this type of connection. Odd that the tables show it should work, > > > > Heikki should know more about this. > > > > > > The firmware probable has not implemented UCSI on this board. I think > > > Dell always supplies the ACPI device node for UCSI in their acpi > > > tables. The _STA method in that device node is then used to inform the > > > OS if the interface exists or not. The return value for _STA comes > > > probable from BIOS, so this is most likely a BIOS problem. > > > > Heikki, > > > > I confirmed with internal team that UCSI is implemented on XPS 9370 > > and was confirmed to be working properly with Windows 10 RS2+. > > Just to double check: "UCSI was confirmed working properly", so not > "the Type-C ports were confirmed working properly"? UCSI was confirmed working properly. FWIW it's a certification requirement in Windows. > > > The reason that _STA is responding on this device node now but wasn't > > previously is it wasn't exposed in Linux until 4.16 when the Win 10 RS2 > > OSI string started to respond. > > OK. > > > Intel should internally have some XPS 9370 you can remotely access if > > you would like to poke around ACPI tables some. > > I will try get access to XPS 9370, but with the acpi tables, if > somebody could just send me acpidump, that would be enough: > > % acpidump -o xps9370_acpi.dump > > > > Please note that UCSI will only supply status information to the > > > operating system, so the USB Type-C ports will function normally even > > > without it. The ports are handled in firmware on these platforms. > > > > > > Paul, do you have the latest BIOS? > > > > > > > > > > > > Does normal USB devices work with it? > > > > > > > > > > Sorry for being ignorant, but could you please tell me what normal USB > > > > > devices are? > > > > > > > > If you plug a USB typeC device into this port, does it work? A docking > > > > station is a little bit "different" in that it usually uses the PCIe > > > > connection, not the USB connectors. Or at least that's how my Dell > > > > docking station works last time I tried it[1] > > > > I think the best description here is "Non-Thunderbolt" USB type C device. > > Some examples: > > There are Dell docking stations with Thunderbolt (TB16) or without (WD15). > > > > You can also pick up little dongles for ethernet or combo dongles for > > ethernet/VGA/HDMI/etc. > > > > Anything non-Thunderbolt would satisfy what Greg was looking for. > > Anything non-Thunderbolt and non-display. > > With the display adapters you would be in DisplayPort alternate mode, > and you would again not be testing a normal USB device. > > It never hurts to check that, but I think it's safe to assume that the > ports are functioning normally if the Thunderbolt dock was working. > Unless I'm mistaken, even the xHCI USB host controller behind the > USB Type-C (thunderbolt) ports is actually part of the thunderbolt > controller. In this laptop yes that's true, but isn't a general statement. It's possible to have USB split mode (ie XHCI comes from PCH). -- 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
