On Wed, Jan 25, 2017 at 12:27:28PM +0200, Felipe Balbi wrote: > > Hi, > > Heikki Krogerus <[email protected]> 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. -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
