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: > > Hi Oliver, > > > > On Fri, May 20, 2016 at 04:19:59PM +0200, Oliver Neukum wrote: > > > On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote: > > > > Like I've told some of you guys, I'm trying to implement a bus for > > > > the Alternate Modes, but I'm still nowhere near finished with that > > > > one, so let's just get the class ready now. The altmode bus should in > > > > any case not affect the userspace interface proposed in this patch. > > > > > > Is this strictly divorced from USB PD? > > > > The bus can not be tied to the USB PD stack we will have in the > > kernel completely, or there is no change of using it with things like > > UCSI. It's going to be difficult to achieve that in any case as we > > simply won't be able to send and rescieve the VDMs with things like > > UCSI, but let's see. > > > > > How do you trigger a cable reset or a USB PD reset? > > > > There needs to be an API, but I'm sure that's not going to be a > > problem. The bus and the altmode specific drivers will reside inside > > kernel. > > Absolutely. But at some point we need to settle on an API. > If I am to tell you whether your proposed API leaves out > something that needs to be covered, I need to know what > is to go into the other APIs. > > 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. > > But I'm getting the sense that you are thinking about having some > > responsibility of USB PD in userspace. Please correct me if I'm wrong. > > Gods help us all if we are ready to do that. > It would fail. > Yet I think the idea that PD and Alternate Modes can be cleanly > divorced is wrong. The selection of Alternate Modes is done by > USB PD messages. We can encapsulate that, but we cannot leave it out, > especially in the area of resets. > > > I don't think it will be possible. I think the role of userspace can > > only be the source for high level requests via this interface, like > > enter/exit mode and swap role, and receiving the status and details of > > the ports, but any knowledge about the requirements regarding those > > steps belongs to the kernel. This includes also the knowledge about > > Yes. > > > stuff like mode dependencies, for example if cable plug has to be in a > > certain mode in order for the partner to be able to enter some > > specific mode, etc. > > 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. > You covered 1. and 2. > 3. can be covered by specific drivers > 4. and 5. are not covered (and it makes no sense to tie it > to specific drivers) > > 6. and 7. is covered > 8. is not > > And 8. needs to be covered. It affects who selects the Alternate Mode. Doesn't the actual role determine that ? A device which prefers to be a DFP might still end up as UFP. > You cannot tie it to USB and it doesn't fit with pure PD stuff. > > I like your API as it is now. But it is incomplete. > Same here. Thanks, Guenter -- 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
