Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

[Heikki Krogerus]

On Wed, Feb 17, 2016 at 03:36:46PM +0200, Felipe Balbi wrote:
> 
> Hi,
> 
> Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx> writes:
> > On Wed, Feb 17, 2016 at 11:36:52AM +0100, Oliver Neukum wrote:
> >> On Wed, 2016-02-17 at 12:29 +0200, Felipe Balbi wrote:
> >> > Hi,
> >> > 
> >> > Oliver Neukum <oneukum@xxxxxxxx> writes:
> >> > > On Wed, 2016-02-17 at 09:58 +0200, Heikki Krogerus wrote:
> >> > >> On Tue, Feb 16, 2016 at 02:39:47PM +0100, Oliver Neukum wrote:
> >> 
> >> > >> > Yes, but we need an API. We can't keep adding to it. So if that
> >> > >> > is to be supported, it needs to be defined now.
> >> > >> 
> >> > >> When you say API, do you mean the API the class provides to the
> >> > >> drivers? Or did you mean ABI which would be the sysfs in this case?
> >> > >
> >> > > The API to user space. That is the point. We cannot break user space.
> >> > > Once this sysfs API is upstream we are stuck with it.
> >> > 
> >> > yeah, in fact I have been wondering if sysfs is the best interface to
> >> 
> >> That is the discussion we must have.
> >> 
> >> > userspace. I talked with Heikki a few days back about this; I was
> >> > wondering if something like what the NFC folks did with netlink would be
> >> > better here.
> >> 
> >> I doubt that, because the main user is likely to be udev scripts.
> >> They can easily deal with sysfs attributes.
> >
> > IMHO for high level interface like this, sysfs is ideal because of the
> > simple fact that you only need a shell to access the files. netlink
> > would make us depend on custom software, no?
> >
> > I'm not against using netlink, but what would be the benefit from it
> > in this case?
> 
> With HW we see nowadays, CC stack is hidden on some microcontroller, but
> is it too far-fetched to consider a system where this is not the case ?

There already are several USB PD stacks out there, like also Greg
pointed out.

> Specially when we consider things like power delivery which, I know, you
> wanted to keep it out of this interface, however we would have two
> 'stacks' competing for access to the same pins, right ?

No. This class would be the top layer for the coming stack, where ever
it ends up coming. The class is only the interface to the user space
and nothing else.

By saying we need to keep USB Type-C separate from USB PD I meant that
the userspace access can not be mixed somewhere in layers of the USB
PD/CC stack like it has been in the USB PD stacks I've seen so far.
They assume that we always use the software USB PD stack with USB
Type-C, which as we can see is not true when the stack is implemented
in EC or firmware or some complex USB PD controller or what ever.
However, the operations the userspace needs to do are exactly the same
in both cases.

- data role swapping
- power role swapping (depends on USB PD)
- Alternate Modes (depends on USB PD)

And we really should not forget that we actually also have USB Type-C
PHYs that can't do any USB PD communication over the CC pin, so USB PD
is simply not always going to be available. But the data role swapping
and also accessories are still available with them, as the do not need
USB PD.

This was the whole point with the class. It allows the different ways
of dealing with Type-C ports to be exposed to userspace in the same
way.

> IIRC mode and role negotiation goes via CC pins using the power delivery
> protocol. If I misunderstand anything, let me know.

The data role swap with USB Type-C connectors is in no way tied to USB
Power Delivery. The USB Type-C spec defines that when USB PD is
available, DR_Swap USB PD function is used to swap the role, otherwise
emulated disconnect will do the trick.

Data role swapping is a must thing to have with USB Type-C connectors
because of the fact that the role is selected randomly. Regardless was
USB PD supported or not.


Thanks,

-- 
heikki