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

[Guenter Roeck]

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