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 S1753964AbcH3OUA (ORCPT <rfc822;w@1wt.eu>);
        Tue, 30 Aug 2016 10:20:00 -0400
Received: from mga05.intel.com ([192.55.52.43]:55476 "EHLO mga05.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1753271AbcH3OT6 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 30 Aug 2016 10:19:58 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.30,256,1470726000"; 
   d="scan'208";a="755082071"
Date: Tue, 30 Aug 2016 17:13:31 +0300
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Oliver Neukum <oneukum@suse.com>, Greg KH <gregkh@linuxfoundation.org>,
        Vincent Palatin <vpalatin@chromium.org>,
        Bin Gao <bin.gao@linux.intel.com>,
        Felipe Balbi <felipe.balbi@linux.intel.com>,
        linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [PATCHv6 1/3] usb: USB Type-C connector class
Message-ID: <20160830141331.GD1751@kuha.fi.intel.com>
References: <1472474182-43858-1-git-send-email-heikki.krogerus@linux.intel.com>
 <1472474182-43858-2-git-send-email-heikki.krogerus@linux.intel.com>
 <1472549521.2623.10.camel@suse.com>
 <20160830100437.GA1751@kuha.fi.intel.com>
 <fbf390ec-4912-1fb5-f11b-0afc26273924@roeck-us.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <fbf390ec-4912-1fb5-f11b-0afc26273924@roeck-us.net>
User-Agent: Mutt/1.7.0 (2016-08-17)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Aug 30, 2016 at 06:46:24AM -0700, Guenter Roeck wrote:
> On 08/30/2016 03:04 AM, Heikki Krogerus wrote:
> > Hi Oliver,
> > 
> > On Tue, Aug 30, 2016 at 11:32:01AM +0200, Oliver Neukum wrote:
> > > On Mon, 2016-08-29 at 15:36 +0300, Heikki Krogerus wrote:
> > > > +What:          /sys/class/typec/<port>/current_data_role
> > > > +Date:          June 2016
> > > > +Contact:       Heikki Krogerus <heikki.krogerus@linux.intel.com>
> > > > +Description:
> > > > +               The current USB data role the port is operating in.
> > > > This
> > > > +               attribute can be used for requesting data role
> > > > swapping on the
> > > > +               port. Swapping is only supported as an asynchronous
> > > > operation
> > > > +               and requires polling of the attribute in order to know
> > > > the
> > > > +               result, so successful write operation does not mean
> > > > successful
> > > > +               swap.
> > > > +
> > > 
> > > That is badly formulated. Does it mean that poll() or select()
> > > can be used or does the value need to be repearedly read?
> > 
> > Does polling not always mean poll/select?
> > 
> > > And how would you learn about an error?
> > 
> > This is what I'm also really worried about. I'm now wondering did I
> > give up too easily on this to Guenter in hope to move this thing
> > forward. He said it's problematic to do these calls synchronously for
> > him. Was it something related to potential conflicting role swaps from
> > both ends?
> > 
> > Guenter, can you please elaborate? And how do you plan to report
> > failures with the swaps?
> > 
> 
> I thought we had this sorted out. When I said "asynchronous", I did not mean
> that the sysfs operation would not wait for the operation to complete. I meant
> that the Type-C state machine operates in a different context than the sysfs/class
> code. Since the state machine operates in a different context, it may have
> to execute a callback into the class code at any time, independently of
> any pending role changes triggered through sysfs. Please have a look into
> the patch set I submitted for details. Roughly it works as follows.
> 
> Class code context				State machine context
> 
> User requests role change
> Class code calls {dr,pr,vconn}_set
> {dr,pr,vconn}_set code validates request
> {dr,pr,vconn}_set code sends role change
> 	request to state machine		State machine gets role change request
> {dr,pr,vconn}_set code waits for completion
> 						State machine sends role change request
> 						to link partner
> 						Partner reports Accept or Reject
> 						State machine changes state as requested
> 						State machine reports new role to class code
> 							via callbacks
> 						State machine informs Class code that request
> 						is complete
> {dr,pr,vconn}_set code gets results
> 	and returns to caller
> Class code reports results to user
> 
> From user perspective, everything is synchronous. However, the state machine has to be
> able to run independently and report role and other state changes to the class code while
> a role change request from the class code is pending. For example, it has to be able to
> handle incoming role change requests from the link partner, and it has to be able to
> handle link state changes. All those have to be reported to the class code. This is
> impossible if the class code holds a lock while a role change triggered from user space
> is pending, which is why I asked for the locks in the class code to be removed.
> 
> Maybe my use of the term "asynchronous" was misleading, and I should have said "operates
> in a different context" instead. My apologies.

Thanks for the explanation. I remember you did explain this before I
started my parental leave, but I forgot all about it.


Thanks,

-- 
heikki