Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762544AbdDSLZl (ORCPT ); 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 ); 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 To: Badhri Jagan Sridharan , Oliver Neukum Cc: Guenter Roeck , Mats Karrman , Greg KH , Felipe Balbi , LKML , USB 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: 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//preferred_role > +Date: March 2017 > +Contact: Heikki Krogerus > +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