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]

Message-ID: <CAOiXhaLcCJfgFqz5m8aM=xcWCqeav1FRYwv9RWRg0CYoijHCNw@mail.gmail.com>
Date:   Thu, 27 Apr 2017 11:50:12 +0530
From:   Rajaram R <rajaram.officemail@...il.com>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     Badhri Jagan Sridharan <badhri@...gle.com>,
        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 Tue, Apr 25, 2017 at 7:40 PM, Guenter Roeck <linux@...ck-us.net> wrote:
> 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 ?

The parameters required for a type-c connection is defined as follows
and will have a default value.

/sys/class/typec/<port>/supported_power_roles
/sys/class/typec/<port>/preferred_role

When two DRP devices are connected and for which we have
preferred_role which provides input on the preference, In a DRP mode
we have randomness in the mode of connection and hence we require role
swap mechanisms. A Type-C only device cannot role swap as this is
valid only in PD operation.

#  Question was how to choose a particular role in non-PD mode. Only
way to have a deterministic role in a non-PD mode is to set expected
supported_role of choice rather than DRP.

# As part of the solution suggested, checking of roles and triggering
role swaps has to be done by the policy manager(PM) and delinked from
Policy Engine. I guess the policy manager is at user space?.

I do not have the complete git repo and may be i could be missing
something. If this is in any public git please let me know

>
> Thanks,
> Guenter
>