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 -- 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
