Re: [RFC PATCHv2] usb: USB Type-C Connector Class

[Oliver Neukum <oneukum@suse.com>]

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