linux-kernel - Re: [PATCHv3 1/2] 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: <1466590495.12516.10.camel@suse.com>
Date:	Wed, 22 Jun 2016 12:14:55 +0200
From:	Oliver Neukum <oneukum@...e.com>
To:	Heikki Krogerus <heikki.krogerus@...ux.intel.com>
Cc:	Felipe Balbi <felipe.balbi@...ux.intel.com>,
	Greg KH <gregkh@...uxfoundation.org>,
	Guenter Roeck <linux@...ck-us.net>,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCHv3 1/2] usb: USB Type-C connector class

On Wed, 2016-06-22 at 12:50 +0300, Heikki Krogerus wrote:
> On Tue, Jun 21, 2016 at 10:25:05PM +0200, Oliver Neukum wrote:
> > On Tue, 2016-06-21 at 17:51 +0300, Heikki Krogerus wrote:
> > > +What:          /sys/class/typec/<port>/supported_data_roles
> > > +Data:          June 2016
> > > +Contact:       Heikki Krogerus <heikki.krogerus@...ux.intel.com>
> > > +Description:
> > > +               Lists the USB data roles, host or device, the port is
> > > capable
> > > +               of supporting.
> > 
> > On third thought, this is a problem. Looking at 4.4.8.1
> > DEVICE_CAPABILITIES (Required) of USB Type-C Port Controller
> > Interface Specification we lack capability.
> > 
> > A port that can do DRP is not the same thing as a port that
> > can be switched between DFP and UFP. We cannot express that.
> 
> What do you mean? DRP means we support and are able to swap the data

No. That is the error. We support them concurrently. And that is not
obvious. It is perfectly possible to support both but not concurrently.

> role, but it just does not mean we can act as both source and sink. And
> that information we already get from separate attribute:
> "supported_power_roles".

But it is different. Suppose we have a port that can be switched between
UFP and DFP, as the spec defines. If it is switched to DFP and we plug
in a DFP it will not work. UFP into UFP has the same result.

Plugging it into a DRP will always work.

It is true that both support host and device, but the capability of
the ports is different. And that is not expressed.

	Regards
		Oliver