Hi, Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx> writes: >> Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx> writes: >> >> > + 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. >> >> That means we need some method for figuring out VBUS is above 4.4V. > > The VBUSOK bit means VBUS valid. okay, good. Then we're settled. -- balbi
Attachment:
signature.asc
Description: PGP signature