lkml.org 
[lkml]   [2016]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCHv2] usb: USB Type-C Connector Class
On Wed, May 25, 2016 at 08:19:47AM -0700, Guenter Roeck wrote:
> On Wed, May 25, 2016 at 02:28:46PM +0300, Heikki Krogerus wrote:
> > Hi,
> >
> > On Tue, May 24, 2016 at 02:51:40PM +0200, Oliver Neukum wrote:
> > > On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> > >
> > > Hi,
> > >
> > > as this discussion seems to go in circles, I am starting anew
> > > at the top.
> > >
> > > > 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.
> > > >
> > > > As you can see, the Alternate Modes are handled completely differently
> > > > compared to the original proposal. Every Alternate Mode will have
> > > > their own device instance (which will be then later bound to an
> > > > Alternate Mode specific driver once we have the bus), but also every
> > > > partner, cable and cable plug will have their own device instances
> > > > representing them.
> > >
> > > The API works for a DFP. I fail to see how the UFP learns about entering
> > > an alternate mode.
> > > Secondly, support to trigger a reset is missing
> >
> > I'm fine with adding an attribute for port and cable resets if it's
> > something that is needed. So do you want to be able to execute hard
> > reset on a port?
> >
> > But could you please explain the case(s) where you need to tricker a
> > reset.
> >
> > > > An other change is that the data role is now handled in two ways.
> > > > The current_data_role file will represent static mode of the port, and
> > > > it will use the names for the roles as they are defined in the spec:
> > > > DFP, UFP and DRP. This file should be used if the port needs to be
> > >
> > > Good, but support for Try.SRC and Try.SNK is missing.
> >
> > OK, but what is Try.SNK? It's not in the specs?
> >
>
> It is not in the USB PD specification, but in "USB Type-C Specification
> Release 1.2 - Cable and Connector Specification".
>
> Section 4.5.2.2.11, "Try.SNK State", says
>
> "Note: if both Try.SRC and Try.SNK mechanisms are implemented, only one
> shall be enabled by the port at any given time. Deciding which of these
> two mechanisms is enabled is product design-specific."
>
> ... which is why I suggested earlier that there should be a platform
> parameter to enable one or the other.

Heh, I'm still living the year 2015 :). I've missed the Type-C 1.2
spec.


Thanks guys,

--
heikki

\
 
 \ /
  Last update: 2016-05-27 09:41    [W:0.117 / U:0.684 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site