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

[Oliver Neukum]

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.

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

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

	Regards
		Oliver