From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751760AbcFWM0l (ORCPT ); Thu, 23 Jun 2016 08:26:41 -0400 Received: from bear.ext.ti.com ([198.47.19.11]:59170 "EHLO bear.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751272AbcFWM0k (ORCPT ); Thu, 23 Jun 2016 08:26:40 -0400 Subject: Re: [PATCHv3 1/2] usb: USB Type-C connector class To: Heikki Krogerus , Oliver Neukum References: <1466520711-125758-2-git-send-email-heikki.krogerus@linux.intel.com> <1466540705.2014.11.camel@suse.com> <20160622095016.GB19856@kuha.fi.intel.com> <1466590495.12516.10.camel@suse.com> <20160622114458.GF19856@kuha.fi.intel.com> <1466603223.16513.2.camel@suse.com> <20160622143803.GG19856@kuha.fi.intel.com> <1466613858.1976.5.camel@suse.com> <20160623082307.GA27263@kuha.fi.intel.com> <1466671138.2556.5.camel@suse.com> <20160623120055.GC27263@kuha.fi.intel.com> CC: Felipe Balbi , Greg KH , Guenter Roeck , , From: Roger Quadros Message-ID: <576BD54A.8050800@ti.com> Date: Thu, 23 Jun 2016 15:25:46 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160623120055.GC27263@kuha.fi.intel.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 23/06/16 15:00, Heikki Krogerus wrote: > Hi Oliver, > > On Thu, Jun 23, 2016 at 10:38:58AM +0200, Oliver Neukum wrote: >> On Thu, 2016-06-23 at 11:23 +0300, Heikki Krogerus wrote: >>> On Wed, Jun 22, 2016 at 06:44:18PM +0200, Oliver Neukum wrote: >> >>> No it's not. DRP means a port that can operate as _either_ Source >>> (host) or Sink (device), but not at the same time.. >> >> Yes, but it is unclear what you will be after a connection >> and that's the point. > > Which is a fact that we can do nothing about. The role after > connection with DRP ports will be dictated by the partner or selected > randomly in case the partner is also DRP. We can prefer a role, but > that in the end guarantees nothing. So if the role that we end up with > after connection (seen in current_data_role) does not satisfy us, all > we can do is try to swap it. > > I'm not sure what is your point here. What if the application wants to know exactly what role the device is operating in at the current moment? We need to have 2 distinct parameters. 1) supported_modes : host, device, host or device 2) current_mode: host, device, disconnected -- cheers, -roger