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

[Oliver Neukum]

On Mon, 2016-05-23 at 10:09 -0700, Guenter Roeck wrote:
> On Mon, May 23, 2016 at 01:25:19PM +0200, Oliver Neukum wrote:
> > On Mon, 2016-05-23 at 12:57 +0300, Heikki Krogerus wrote:
> >
> > A reset is a generic function, so it does not belong to specific
> > drivers.
> > 
> A would expect the driver to execute the reset.
> 
> Maybe the question should be phrased differently: Even USCI (which
> doesn't provide for everything) has commands to reset the policy
> manager and to reset the connector. The class should provide a means
> to execute those commands.

Yes.

> > So for Alternate Modes we need on a high level the following features
> > 
> > 1. discovery of available Alternate Modes
> > 2. selection of an Alternate Mode
> > 3. notification about entering an Alternate Mode
> > 4. triggering a reset
> > 5. notification about resets
> > 
> > 6. discovery about the current role
> > 7. switching roles
> > 8. setting preferred roles (Try.SRC and Try.SNK)
> > 
> 
> Isn't reset and role handling orthogonal to alternate mode functionality ?
> Both will still be needed even if alternate mode support is not implemented
> at all.

In part. A reset can cause the Alternate Mode to be left unexpectedly
and unintentionally.
So how many APIs do we want?
Three:

- Alternate Modes
- USB PD
- type C for roles and reset

Or another number?

> > I like your API as it is now. But it is incomplete.
> > 
> 
> Same here.

So what is to be done?

	Regards
		Oliver