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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160525151947.GB19413@roeck-us.net>
Date:	Wed, 25 May 2016 08:19:47 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Heikki Krogerus <heikki.krogerus@...ux.intel.com>
Cc:	Oliver Neukum <oneukum@...e.com>,
	Andy Shevchenko <andy.shevchenko@...il.com>,
	Rajaram R <rajaram.officemail@...il.com>,
	Felipe Balbi <felipe.balbi@...ux.intel.com>,
	Mathias Nyman <mathias.nyman@...ux.intel.com>,
	Greg KH <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [RFC PATCHv2] usb: USB Type-C Connector Class

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.

Guenter