linux-kernel - Re: [PATCH v17 2/3] 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:   Tue, 25 Apr 2017 07:10:48 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Rajaram R <rajaram.officemail@...il.com>,
        Badhri Jagan Sridharan <badhri@...gle.com>
Cc:     Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Oliver Neukum <oneukum@...e.com>,
        Mats Karrman <mats.dev.list@...il.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Felipe Balbi <felipe.balbi@...ux.intel.com>,
        LKML <linux-kernel@...r.kernel.org>,
        USB <linux-usb@...r.kernel.org>
Subject: Re: [PATCH v17 2/3] usb: USB Type-C connector class

On 04/25/2017 01:26 AM, Rajaram R wrote:
> On Mon, Apr 24, 2017 at 11:20 PM, Badhri Jagan Sridharan
> <badhri@...gle.com> wrote:
>> On Sat, Apr 22, 2017 at 2:23 AM, Rajaram R <rajaram.officemail@...il.com> wrote:
>>> On Fri, Apr 21, 2017 at 10:13 PM, Guenter Roeck <linux@...ck-us.net> wrote:
>>>> On Fri, Apr 21, 2017 at 07:57:52PM +0530, Rajaram R wrote:
>>>>> On Fri, Apr 21, 2017 at 1:16 AM, Badhri Jagan Sridharan
>>>>> <badhri@...gle.com> wrote:
>>>>>> Thanks for the responses :)
>>>>>>
>>>>>> So seems like we have a plan.
>>>>>>
>>>>>> In Type-C connector class the checks for TYPEC_PWR_MODE_PD
>>>>>> and pd_revision for both the port and the partner will be removed in
>>>>>> power_role_store and the data_role_store and will be delegated
>>>>>> to the low level drivers.
>>>>>
>>>>> It is important to remember what USB Type-C provide is mechanisms for
>>>>> "TRYing" to become a particular role and not guaranteeing.
>>>>>
>>>>> With what device combination do you fore see we could get the desired
>>>>> role with this change ?
>>>>>
>>>>
>>>> If the partner is not PD capable, if a preferred role is specified,
>>>> if the current cole does not match the preferred role, and if the request
>>>> is to set the role to match the preferred role, I think it is reasonable
>>>> to expect that re-establishing the connection would accomplish that if the
>>>> partner supports it.
>>>>
>>> In this context I believe we have two different inputs as follows:
>>>
>>> /sys/class/typec/<port>/supported_power_roles
>>> /sys/class/typec/<port>/preferred_role
>>>
>>> The need of preferred role is required when DRP is set in
>>> supported_power_roles option.
>>> Ideally a battery powered device will TRY to be SNK and a a/c plugged
>>> device will TRY to be SRC
>>>
>>> We need to understand which non-PD device will set to DRP? In the
>>
>> Android Phones (actually it could be any phone which has a type-c port)
>> since it can act as usb gadget (when connected to PC) or Usb host
>> when connected to peripherals such as thumb drives, keyboard etc.
>> Phones with smaller form factors might be thermally limited to charge
>> above 15W, therefore supporting PD might be an overkill for them.
>>
>>> current ecosystem all legacy devices
>>> will sit behind adapters which either present an Rp or Rd.
>>>
>>> If it is a power adapter in 5V range can either present Rp or DRP with
>>> TRY.SRC and there is no role swap requirement.
>>>
>>> If it is a laptop port or similar with non-PD (??) DRP  there is no
>>> guaranteed role swap in a non-PD mode.
>>
>> This is true, but following a Try.SRC or Try.SNK state machine can
>> increase the chances of landing in the desired role/preferred role.
>
> Agree and as indicated it increases only chances.
>

FWIW, this is pretty much the same as requesting a role change using PD.
Based on my experience with various devices, the chance for that to succeed
isn't really that high either.

I am not really sure I understand your problem with using Try.{SRC,SNK}
to trigger (or attempt to trigger) a role change. Can we take a step back,
and can you explain ?

Thanks,
Guenter