Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S935739AbdDSOpW (ORCPT <rfc822;w@1wt.eu>);
        Wed, 19 Apr 2017 10:45:22 -0400
Received: from mail-it0-f47.google.com ([209.85.214.47]:35478 "EHLO
        mail-it0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S935390AbdDSOpJ (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 19 Apr 2017 10:45:09 -0400
MIME-Version: 1.0
In-Reply-To: <20170419112323.GD24062@kuha.fi.intel.com>
References: <4b4bbffc-db02-3b54-04bc-e7de79b2d9ed@roeck-us.net>
 <07618170-d561-e7fe-08e0-91316c53d832@gmail.com> <20170303125940.GA6999@kuha.fi.intel.com>
 <6ddb2eac-03d5-127e-df1e-ad189968e6b2@gmail.com> <20170306131442.GC6999@kuha.fi.intel.com>
 <696552a7-c36a-1d73-9517-543907e9da39@gmail.com> <20170308135853.GH6999@kuha.fi.intel.com>
 <68817c44-d880-581a-e9f5-12845b9215eb@gmail.com> <ce0350a4-f7d9-3fdd-88ee-8cb827ecee2a@roeck-us.net>
 <CAPTae5+O83bJm6KL2zWNhYv-SiZ2E490CLt02BbK4hG1xKXraw@mail.gmail.com> <20170419112323.GD24062@kuha.fi.intel.com>
From: Badhri Jagan Sridharan <badhri@google.com>
Date: Wed, 19 Apr 2017 07:45:00 -0700
Message-ID: <CAPTae5+C5xVqEbq2v+J+OWh8srsbS-fM612Sbu5Cq6MSgmRr7g@mail.gmail.com>
Subject: Re: [PATCH v17 2/3] usb: USB Type-C connector class
To: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Oliver Neukum <oneukum@suse.com>, Guenter Roeck <linux@roeck-us.net>,
        Mats Karrman <mats.dev.list@gmail.com>,
        Greg KH <gregkh@linuxfoundation.org>,
        Felipe Balbi <felipe.balbi@linux.intel.com>,
        LKML <linux-kernel@vger.kernel.org>, USB <linux-usb@vger.kernel.org>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 3483
Lines: 89

On Wed, Apr 19, 2017 at 4:23 AM, Heikki Krogerus
<heikki.krogerus@linux.intel.com> wrote:
> Hi,
>
> On Tue, Apr 18, 2017 at 11:52:33AM -0700, Badhri Jagan Sridharan wrote:
>> Hi Heikki,
>>
>> I have a question regarding the preferred_role node.
>>
>> +What:          /sys/class/typec/<port>/preferred_role
>> +Date:          March 2017
>> +Contact:       Heikki Krogerus <heikki.krogerus@linux.intel.com>
>> +Description:
>> +               The user space can notify the driver about the preferred role.
>> +               It should be handled as enabling of Try.SRC or Try.SNK, as
>> +               defined in USB Type-C specification, in the port drivers. By
>> +               default the preferred role should come from the platform.
>> +
>> +               Valid values: source, sink, none (to remove preference)
>>
>> What is the expected behavior when the userspace changes the
>> preferred_role node when the port is in connected state ?
>>
>> 1.  the state machine re-resolves the port roles right away based on
>> the new state machine in place ? (or)
>
> No! There are separate attributes for sending role swap requests.

Right. But, that might not be helpful in cases when PD is not implemented.
and Implementing PD is not mandatory according the spec :/

FYI quoting from the Type-C specification release(page 24),
role swaps are not limited to devices that only support PD.

"Two independent set of mechanisms are defined to allow a USB Type-C
DRP to functionally swap power and data roles. When USB PD is
supported, power and data role swapping is performed as a subsequent
step following the initial connection process. For non-PD implementations,
power/data role swapping can optionally be dealt with as part of the initial
connection process."

But, the current interface definition actually prevents current/data role
swaps for non-pd devices.

>
> The attribute will "enable" Try.SRC/SNK states, i.e. next time the
> state machine is executed, those states need to be considered.
> Changing the value of this attribute must not affect the current
> connection.
>
>> 2. Wait till the subsequent connect for resolving port roles based on the
>> new state machine.
>
> Yes.
>
>> For #1 to happen the policy_engine layer would have to reset the port
>> to resolve the port roles based on the (Try.SRC /Try.SNK/ Default)
>> new state machine preference.
>>
>> Say for example when two non-PD devices following none (default state
>> machine) are connected, the port role resolution is going to be random.
>> But, if the userspace in one of the devices later changes the
>> preferred_role to source, then that device is most likely to become source
>> if the Try.SRC state-machine is re-run.
>>
>> Does the above question fall under a policy decision ? If so, should there
>> be another node to say if the port roles have to re-resolved  based on the
>> new state machine right away ?
>
> I don't think we should even consider option #1, but just to be sure,
> Oliver, what do you say?

Can we at least consider exposing a port_reset field so that the userspace
at least has an option to make the state machine to kick in right away with
a hard reset ?

Please do consider. We can't expect all low-end phones and devices with
smaller form factors then phones to implement PD as it might be an overkill
for them.

>
> I guess we need to say in the documentation explicitly that changing
> the value will not affect the current connection.
>
>
> Thanks,
>
> --
> heikki