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 S932682AbcH3LuD (ORCPT <rfc822;w@1wt.eu>);
        Tue, 30 Aug 2016 07:50:03 -0400
Received: from mga14.intel.com ([192.55.52.115]:55394 "EHLO mga14.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S932610AbcH3LuB (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 30 Aug 2016 07:50:01 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.30,256,1470726000"; 
   d="scan'208";a="1033113876"
Date: Tue, 30 Aug 2016 14:49:50 +0300
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Oliver Neukum <oneukum@suse.com>
Cc: Guenter Roeck <linux@roeck-us.net>,
        Vincent Palatin <vpalatin@chromium.org>,
        Bin Gao <bin.gao@linux.intel.com>,
        Felipe Balbi <felipe.balbi@linux.intel.com>,
        Greg KH <gregkh@linuxfoundation.org>, linux-kernel@vger.kernel.org,
        linux-usb@vger.kernel.org
Subject: Re: [PATCHv6 1/3] usb: USB Type-C connector class
Message-ID: <20160830114950.GB1751@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>
 <1472555806.2623.16.camel@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1472555806.2623.16.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

On Tue, Aug 30, 2016 at 01:16:46PM +0200, Oliver Neukum wrote:
> On Tue, 2016-08-30 at 13:04 +0300, Heikki Krogerus wrote:
> > On Tue, Aug 30, 2016 at 11:32:01AM +0200, Oliver Neukum wrote:
> 
> Hi,
> 
> > > 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?
> 
> No, it does not.
> 
> > > 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
> 
> Error reporting does not require a synchronous operation. Reporting
> it in the next read() or write() and making it pollable is perfectly
> viable. It just must not be silently dropped.

OK, I think I got it. I need to document that. I'll also add
get_pr/dr/vconn hooks to the API for getting the status.


Thanks Oliver,

-- 
heikki