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: <20160623082307.GA27263@kuha.fi.intel.com>
Date:	Thu, 23 Jun 2016 11:23:07 +0300
From:	Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:	Oliver Neukum <oneukum@...e.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, Jun 22, 2016 at 06:44:18PM +0200, Oliver Neukum wrote:
> On Wed, 2016-06-22 at 17:38 +0300, Heikki Krogerus wrote:
> > On Wed, Jun 22, 2016 at 03:47:03PM +0200, Oliver Neukum wrote:
> > > On Wed, 2016-06-22 at 14:44 +0300, Heikki Krogerus wrote:
> > > > If our port is DRD (which would be DRP in the port controller spec),
> > > > the supported_power_roles will list:
> > > > 
> > > >         device, host
> > > > 
> > > > And the power role, if the port is Source only, the
> > > > supported_power_roles will list:
> > > > 
> > > >         source
> > > > 
> > > > If the port is Sink only, the supported_power_roles will list:
> > > > 
> > > >         sink
> > > > 
> > > > If our port is DRP, the supported_power_roles will list:
> > > > 
> > > >         source, sink
> > > > 
> > > > What is there that is missing? We are able to express all the types of
> > > > "Roles Supported" that the DEVICE_CAPABILITIES define, no?
> > > 
> > > No, because these are distinct in time. Some ports are DRP so they
> > > support
> > > 
> > > device, host
> > > 
> > > at the same time. Some ports can be switched between DFP and UFP
> > > they then either support host or device. But you lose the information
> > > that the ports can be switched.
> > 
> > You can't ever be host and device at the same time. Just like you
> > can't ever be source and sink at the same time.
> 
> True, but you can be able to become host and device at the same time.

No you can't..

> That is the purpose of a DRP port.

No it's not. DRP means a port that can operate as _either_ Source
(host) or Sink (device), but not at the same time..

> And you can be able to become a host and be able to become a device.
> But not at the same time. These ports are switchable.
> 
> The current API cannot express the difference.

I think you have misunderstood something. The only case where the port
can be dual-role is if it's set to be DRP. Otherwise it's Source only
OR Sink only.

The "Role Supported" bits only tell us how we can program for example
the ROLE_CONTROL registers. I guess the "Roles Supported" bits in
DEVICE_CAPABILITIES are not explained properly, so let's go over them
here:

000b = Source _or_ Sink only
001b = Source only
010b = Sink only
011b = Sink only with support for autonomously detected accessory modes
100b = DRP only, and this I believe mean we can not program the port
        to be Sink only or Source only
101b = Source only OR Sink only OR DRP, plus ability to detect
        accessories and I guess also cables autonomously
110b = Source only OR Sink only OR DRP

So where the spec lists "Source, Sink", it actually should have said
"Source only OR Sink only".

But you still have only the following options for a port:
1) Source only (host)
2) Sink only (device)
3) DRP (device, host)


Thanks,

-- 
heikki