Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1762544AbdDSLZl (ORCPT <rfc822;w@1wt.eu>);
        Wed, 19 Apr 2017 07:25:41 -0400
Received: from mga01.intel.com ([192.55.52.88]:28999 "EHLO mga01.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1761640AbdDSLZi (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 19 Apr 2017 07:25:38 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.37,221,1488873600"; 
   d="scan'208";a="958686808"
Date: Wed, 19 Apr 2017 14:23:23 +0300
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Badhri Jagan Sridharan <badhri@google.com>,
        Oliver Neukum <oneukum@suse.com>
Cc: 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>
Subject: Re: [PATCH v17 2/3] usb: USB Type-C connector class
Message-ID: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAPTae5+O83bJm6KL2zWNhYv-SiZ2E490CLt02BbK4hG1xKXraw@mail.gmail.com>
User-Agent: Mutt/1.8.0 (2017-02-23)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2265
Lines: 61

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.

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?

I guess we need to say in the documentation explicitly that changing
the value will not affect the current connection.


Thanks,

-- 
heikki