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

[Heikki Krogerus]

On Thu, Jun 02, 2016 at 08:30:57AM +0200, Oliver Neukum wrote:
> On Wed, 2016-06-01 at 16:29 -0700, Guenter Roeck wrote:
> > On Wed, Jun 01, 2016 at 11:26:09AM +0200, Oliver Neukum wrote:
> > > On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> > > > Just noticed that the "active" file is for now read only, but it needs
> > > > to be changed to writable. That file will of course provide means for
> > > > the userspace to Exit and Enter modes. But please note that the
> > > > responsibility of the dependencies between the modes, say, if a plug
> > > > needs to be in one mode or the other in order for the partner to enter
> > > > some specific mode, will fall on the Alternate Mode specific drivers
> > > > once we have the altmode bus. I remember there were concerns about
> > > > this in the original thread.
> > > 
> > > There's one thing we haven't touched upon yet. And I cannot really find
> > > an answer in the spec.
> > > 
> > > What do we do if we return from S4 or S3? I think we need to restore
> > > the ALternate Mode because our display may be running over that
> > > Alternate Mode.
> > > If we want to support USB persist we also need to restore data role
> > > after S4.
> > > 
> > I don't have an answer ... but another interesting question.
> > 
> > How do we distinguish between alternate modes supported by a host vs.
> > alternate modes supported by a sink ? typec_capability includes a pointer
> > to alternate modes supportedf by the connector, but it is not clear if
> > those are alternate modes supported as host, or alternate modes supported
> > as device, or alternate modes supported by both.
> 
> I was under the impression that this applies to the current role.
> 
> > This doesn't matter much if only a fixed role is supported, but it does matter
> > for dual role ports. A laptop will typically only support DisplayPort as host,
> > for example.
> > 
> > Any idea ?
> 
> I would state the obvious that we need separate directories for that.
> And how do we express captive cables?

That means we can not present the alternate modes the ports support as
devices, as then we would have potentially two devices presenting the
same mode. Wish we could make those symlinks.. But perhaps we don't
need to present the port alternate modes as devices in any case.

But there is an other problem. The alternate modes a port can
support as host or device may be defined by the platform, but it can
also be dictated by the alternate mode spec itself. Knowing about the
platform is a problem for the port driver, but knowing about the
individual alternate modes is not. Those will be problems for the
alternate mode drivers in the end.

So the moment a port driver is expected to create the attributes (or
populate the devices) that will present the alternate modes it
supports, this thing will not always be clear to it.

I'm now wondering should we make it responsibility for the port
drivers to generate those attributes that present the alternate modes
they support after all?


Thanks,

-- 
heikki