From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S944376AbdDTLzk (ORCPT <rfc822;w@1wt.eu>);
        Thu, 20 Apr 2017 07:55:40 -0400
Received: from mga03.intel.com ([134.134.136.65]:14510 "EHLO mga03.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S943007AbdDTLzh (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 20 Apr 2017 07:55:37 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.37,225,1488873600"; 
   d="scan'208";a="1121710597"
Date: Thu, 20 Apr 2017 14:55:29 +0300
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Badhri Jagan Sridharan <badhri@google.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>
Subject: Re: [PATCH v17 2/3] usb: USB Type-C connector class
Message-ID: <20170420115529.GA4769@kuha.fi.intel.com>
References: <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>
 <CAPTae5+C5xVqEbq2v+J+OWh8srsbS-fM612Sbu5Cq6MSgmRr7g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAPTae5+C5xVqEbq2v+J+OWh8srsbS-fM612Sbu5Cq6MSgmRr7g@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

Hi,

On Wed, Apr 19, 2017 at 07:45:00AM -0700, Badhri Jagan Sridharan wrote:
> >> 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.

No it doesn't. When USB PD is not supported, you can still use
data_role to swap the role. Of course, the lower level driver may
not support any role swapping in that case.


Thanks,

-- 
heikki