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]

Date:	Sun, 22 May 2016 08:54:38 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Oliver Neukum <oneukum@...e.com>
Cc:	Heikki Krogerus <heikki.krogerus@...ux.intel.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

Hi Oliver,

On 05/20/2016 11:43 PM, Oliver Neukum wrote:
> On Fri, 2016-05-20 at 22:51 -0700, Guenter Roeck wrote:
>> On 05/20/2016 06:37 AM, Oliver Neukum wrote:
>>> On Fri, 2016-05-20 at 14:24 +0300, Heikki Krogerus wrote:
>>>> On Thu, May 19, 2016 at 04:47:17PM +0200, Oliver Neukum wrote:
>>>>>
>>>>> Please explain. How does that express DRP but prefered master?
>>>>
>>>> Sorry but I'm not sure what you mean here. If the port is capable of
>>>> being used as dual role port (DRP in the supported_data_roles file),
>>>> that is the only case where you can select the role with this file. So
>>>> I would imagine that in your case you want to make the port act as
>>>> DFP only, right? But if the port is capable of acting only as UFP, you
>>>> are stuck with that role.
>>>
>>> How do I trigger that Try.SRC is to be used on a port?
>>>
>>
>> This would be part of the USB PD protocol, ie probably outside the scope
>> of the class code. In my implementation, I enable Try.SRC or Try.SNK based
>> on the platform's preferred role.
>
> Hi,
>
> from a purely formal point of view that makes sense.
>
>>>From a usability viewpoint I'd ideally want all controls
> for role at one place. And possibly the controls for modes
> at the same place.
>
> I think part of the problem here is that we lack a statement
> of mission. What are these controls for?
> Merely for controlling modes and providing information
> about modes? And to use neutral terms only for the "master"
> side or both sides?
>

Good question. I originally added a sysfs attribute 'preferred-mode' to
my code, but then concluded that this is supposed to be provided
by the platform and added it as platform data instead, with (currently)
no means to report it to user space.

Heikki's current code doesn't really match the semantics of a 'preferred'
mode, at least not as I read it. In my understanding, 'preferred mode'
means "this is a DRP port which prefers to be a source/sink". In Heikki's
code, one can fix the mode to source or sink, but that doesn't support
situations such as "this port prefers to be a source, but is currently
a sink because the link partner happens to be a charger or refuses to act
as sink for some other reason".

Given that, my working assumption is that preferred mode handling is supposed
to be outside the scope of the infrastructure. I am happy to be corrected,
though.

On a side note, are you working on a USB-PD implementation as well ?

Thanks,
Guenter