Re: USB Type-C hub detection is flaky

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Fri, Jun 29, 2018 at 10:26:46PM +0200, Timur Krist?f wrote:
> Hi Heikki,
> 
> On Fri, 2018-06-29 at 14:42 +0300, Heikki Krogerus wrote:
> > Hi Tim,
> > 
> > On Tue, Jun 26, 2018 at 02:10:57PM +0200, Timur Krist?f wrote:
> > > > Can you send the dmesg output after you have plugged the powered
> > > > and
> > > > non-powered hubs:
> > > 
> > > Right now I have the Dell Type-C to USB 3.0 Type-A adapter with the
> > > USB
> > > 2.0 hub here. There is a Logitech received plugged into the hub.
> > > (So I
> > > can quickly see if it works or not.)
> > > 
> > > After some trial-and-error I figured out when it works and when
> > > not.
> > > Tests were performed on Fedora 28 with kernel 4.17.2.
> > > 
> > > Basically it always works just on the first try. In other words,
> > > when I
> > > power up the USB 2.0 hub and plug it in, then it works. If I plug
> > > it
> > > out, but keep it powered and plug it back in again, it stops
> > > working.
> > 
> > I wonder if the PD controller or EC firmware is seeing the
> > disconnection. Perhaps we can test it.
> 
> How does the PD controller come into the picture?
> (Assuming you mean PD = Power Delivery?)

PD controllers handle CC logic as well. It means that they are the
components that detect is there something connected to the port or
not.

With USB Type-C connectors, detecting connection happens using
Configuration Channel (CC) which is a line going through the USB
Type-C cable. You always have a specific chip on your platform for
handling the CC line. It may be a component called TCPC (Type-C Port
Controller), or it may be PD controller.

The USB Power Delivery protocol is also used for other things besides
just for negotiating the power levels. The alternate modes for example
use the Vendor Defined Messages (VDM) for communication which are
special messages defined in USB Power Deliver Specification.

> The device I was talking about does not (and should not) deliver any
> power to the laptop. Again this is a powered USB 2.0 hub with the Dell
> Type-C to Type-A adapter, so it does not support PD.
> 
> (Next week I will buy a Type-C hub with PD support so will be able to
> test with that too.)
> 
> > Can you check if have the USB Type-C ports and partners in sysfs
> > folder /sys/class/typec?
> > 
> >         % ls /sys/class/typec/
> >         port0  port0-partner port1
> 
> On kernel 4.17.2 (as packaged by Fedora 28), that directory is empty,
> even though I have something plugged in to all ports.
> 
> > It may be that you need to cherry-pick a few patches from Greg's
> > tree [1][2] that fix an issue we had with the UCSI device on those
> > Dell laptops. Can you build your own kernel?
> > 
> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/co
> > mmit/?h=usb-linus&id=d2d2e3c46be5d6dd8001d0eebdf7cafb9bc7006b
> > [2] https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/co
> > mmit/?h=usb-linus&id=1f9f9d168ce619608572b01771c47a41b15429e6
> 
> How I usually build a kernel is I just use Fedora's config and tools,
> ie. I patch the latest Fedora kernel and build it using 'fedpkg'
> locally. Hope this approach is OK.
> 
> Now I got the latest from the f28 branch (which is 4.17.3 with some
> patches). I added the two patches from above.
> 
> With the patched kernel, the directory is non-empty but it does not
> correctly react to hotplugging and unplugging.
> 
> > But if you can see the ports and partners under that sysfs folder,
> > after you unplug the device, does the port<x>-partner disappears?
> 
> When I have something in every port on bootup I see this:
> 
> $ ls /sys/class/typec/
> port0  port0-partner  port1  port1-partner  port2  port2-partner
> 
> But when I boot the machine with nothing plugged in, and then plug the
> things in later:
> 
> - Type-C adapter with the USB 2.0 hub does not get a "partner" when it
> is hotplugged, only when it is plugged in at boot time. The partner
> correctly disappears when I plug it out but never appears again.

Oh, that most likely means we are not getting any notifications
(interrupts) from the EC firmware. Either the EC firmware is not
generating them, or something goes wrong.

I think there are now two problems we are seeing. The UCSI interface
does not seem to be behaving properly on this laptop :-(. If you
unload and then reload ucsi_acpi module you probable see the
port<x>-partner getting registered.

Can you check if there is any trace output coming from ucsi driver
when you connect a device to the port:

        % mount none -t debugfs /sys/kernel/debug
        % echo 1 > /sys/kernel/debug/tracing/events/ucsi/enable

        plug something to the port

        % cat /sys/kernel/debug/tracing/trace

> - Type-C charger appears as a "partner" when hot-plugged, but the
> partner does not disappear even if I plug it out. Despite this,
> charging continues to work when I plug it back in to any port. Though
> no other partner gets created when I plug it into a different port.

OK, so if the partner device is able to communicate using USB Power
Delivery protocol, the EC firmware creates a normal notification to
the operating system?

> Note that despite the presence of the "partner" Linux still recognizes
> that the laptop is not charging, when the charger is plugged out.

That is because the firmware takes care of the ports, both CC logic,
and also PD communications. UCSI is just a status interface the OS can
use to interface with the ports. It provides basic details about the
ports, like is there something connected to them or not, and also
primitive control over some thing like power and data role (if the
firmware supports it).

> - Type-C to DisplayPort adapter also shows up as a partner only when it
> is present at boot time. Otherwise not. However it still works with any
> of the three Type-C ports.

That is because USB Type-C alternate modes are negotiated using USB PD
protocol.

> > > If it was plugged into another computer but kept powered, it does
> > > not
> > > work with this laptop either. (Until I power the hub off and on
> > > again.)
> > > 
> > > It appears that the Thunderbolt and non-Thunderbolt ports behave
> > > slightly differently, and the same testcases leave wildly different
> > > messages in dmesg. So I will describe what I did and what output I
> > > got
> > > from dmesg.
> > 
> > Did you have a change to test if the problem can be reproduced in
> > Windows too?
> 
> Sorry, not yet but I will get around to it next week.
> (The XPS is my primary work machine so I will have to back up
> everything before trying my luck with Windows.)

Oh, ic. In that case, perhaps somebody else could test this with
Windows?

Mario! Can you guys test if self powered USB hubs get enumerated
normally in Windows on XPS 9370?


Thanks,

-- 
heikki
--
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



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux