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 S1758034AbcH3KEu (ORCPT <rfc822;w@1wt.eu>);
        Tue, 30 Aug 2016 06:04:50 -0400
Received: from mga01.intel.com ([192.55.52.88]:58341 "EHLO mga01.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1755725AbcH3KEn (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 30 Aug 2016 06:04:43 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.30,255,1470726000"; 
   d="scan'208";a="1049088933"
Date: Tue, 30 Aug 2016 13:04:37 +0300
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Oliver Neukum <oneukum@suse.com>, Guenter Roeck <linux@roeck-us.net>
Cc: 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: <20160830100437.GA1751@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1472549521.2623.10.camel@suse.com>
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

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?


Thanks,

-- 
heikki