On Wed, 2016-06-01 at 23:37 -0700, Guenter Roeck wrote: > On 06/01/2016 11:24 PM, Oliver Neukum wrote: > > On Wed, 2016-06-01 at 06:34 -0700, Guenter Roeck wrote: > >> The class code would not explicitly learn about the reset, > >> but it would be informed about the exited modes. > > > > That has drawbacks > > > > Playing devils advocate a bit here > > > - it doesn't tell you what caused the mode to be left (if you > > UFP, it may be the regular command) > > Does it matter ? Potentially yes. Should you restore the last state when the mode is reentered? If it caused the other side to reset, probably not. > > - it is a race against your own command > > It is my understanding that races have to be resolved by the drivers, > since the typec code does not do any locking. This is quite similar > to handling, say, a request to change the vconn source or to change > the power role. Am I missing something ? Yes. There is a fundamental race between Exit Mode and reset if you only report leaving a mode. Drivers can do nothing to prevent it unless reporting resets by themselves. > > - it does not work if you are in basic USB mode > > > Would alternate modes be active in that case ? No and that is the point. A reset happens, presumably because the other side saw an error condition and we just blindly continue because no Alternate Mode was left and our user space remains uninformed. Regards Oliver -- 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
