From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752454AbcFWNLg (ORCPT ); Thu, 23 Jun 2016 09:11:36 -0400 Received: from mga11.intel.com ([192.55.52.93]:14354 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752212AbcFWNLf (ORCPT ); Thu, 23 Jun 2016 09:11:35 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,509,1459839600"; d="scan'208";a="993634846" Date: Thu, 23 Jun 2016 16:11:30 +0300 From: Heikki Krogerus To: Roger Quadros Cc: Oliver Neukum , Felipe Balbi , Greg KH , Guenter Roeck , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [PATCHv3 1/2] usb: USB Type-C connector class Message-ID: <20160623131130.GE27263@kuha.fi.intel.com> References: <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> <576BD54A.8050800@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <576BD54A.8050800@ti.com> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 23, 2016 at 03:25:46PM +0300, Roger Quadros wrote: > 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 And we already do. But that is not the topic of this thread. Oliver I believe feels that we are not presenting all the capabilities of the ports. Cheers, -- heikki