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: <5743053D.5060307@roeck-us.net>
Date:	Mon, 23 May 2016 06:27:25 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Oliver Neukum <oneukum@...e.com>
Cc:	Andy Shevchenko <andy.shevchenko@...il.com>,
	Rajaram R <rajaram.officemail@...il.com>,
	Felipe Balbi <felipe.balbi@...ux.intel.com>,
	Heikki Krogerus <heikki.krogerus@...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 05/22/2016 10:34 PM, Oliver Neukum wrote:
> On Sun, 2016-05-22 at 08:54 -0700, Guenter Roeck wrote:
>> 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.
>
> Mode or role? I would say that the choice of alternate modes belongs to

s/preferred mode/preferred role/g

> user space. THere's no point in giving a preference to the kernel.
> Role is different. Try.SRC is part of the standard (and Try.SNK has been
> added). It needs to be in kernel space.
>
> Now, if you say that this API is for selecting modes only, then I say it
> lacks support for cable resets and notifications thereof. Yes, that is a
> PD feature, but that doesn't help us. It changes the mode.
>
>> 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".
>
> Yes. That is why we need a mission statement. We may be talking
> a rice cooker not preparing tea here.
>
>> 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 ?
>
> No, one of my task is to to make use of USB PD (and alternate modes)
> in a distribution.
>
> 	Regards
> 		Oliver
>
>
>