On Mon, Jan 23, 2017 at 04:20:08PM +0200, Felipe Balbi wrote:
> Heikki Krogerus <heikki.kroge...@linux.intel.com> 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?
I don't think there is any other way to fix this expect modifying BIOS.
The VBUS_VALID bit would need to be handled separate in ASL.
Cheers,
--
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
