Hi,
Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx> writes:
> +static int wcove_typec_probe(struct platform_device *pdev)
> +{
[snip]
> + wcove->cap.prefer_role = TYPEC_NO_PREFERRED_ROLE;
we have a slight problem here that affects users of this particular
driver. Well, more specifically, it affects Intel Joule.
Because of the way ASL was written and the way Intel's DRD mux works, we
don't have a state which means "don't route USB signals to either Host
or Peripheral". Because of that, when we plug the type-c cable either
XHCI or dwc3 will have noise coming into the IP.
If default mode ends up being peripheral we have two possible problems
here:
i) device-to-device cable assembly
this won't be a big problem because we will just negotiate who's
Sink and who's Source then change mux on one side.
ii) lack of disconnect IRQ on dwc3
Because of how ASL was written, when we unplug the cable, mux's
VBUS_VALID bit won't be cleared which means dwc3 won't generate
disconnect interrupt. This means that upon cable reconnect (!!)
we will run ->disconnect() callback. The result is that dwc3
will never runtime suspend.
If default mode ends up being host we're possibly going to end up with a
host-to-host cable assembly. Now this can cause 2 issues:
i) port config error
host-to-host is not a supported cable assembly. While we see
errors on dmesg, eventually type-c negotiation will happen and
nothing will actually break.
ii) DbC can start on the other end of the cable
Now this was really surprising to me. When testing this on Intel
Joule and plugging Intel Joule straight to my PC's roothub port,
I noticed Joule ended up being host and my Desktop (!!!!) became
a peripheral enumerated by Joule. I can only assume this is DbC
somehow being started.
The only way to have Joule become a peripheral is to connect it
through an external hub to my PC. Odd, ain't it?
I'm not sure how to solve this problem apart from modifying BIOS :-( Any
ideas?
--
balbi
Attachment:
signature.asc
Description: PGP signature
