From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752490AbcFVLpK (ORCPT ); Wed, 22 Jun 2016 07:45:10 -0400 Received: from mga03.intel.com ([134.134.136.65]:58855 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751453AbcFVLpJ (ORCPT ); Wed, 22 Jun 2016 07:45:09 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,509,1459839600"; d="scan'208";a="723333623" Date: Wed, 22 Jun 2016 14:44:58 +0300 From: Heikki Krogerus To: Oliver Neukum Cc: 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: <20160622114458.GF19856@kuha.fi.intel.com> References: <1466520711-125758-1-git-send-email-heikki.krogerus@linux.intel.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1466590495.12516.10.camel@suse.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 Wed, Jun 22, 2016 at 12:14:55PM +0200, Oliver Neukum wrote: > On Wed, 2016-06-22 at 12:50 +0300, Heikki Krogerus wrote: > > On Tue, Jun 21, 2016 at 10:25:05PM +0200, Oliver Neukum wrote: > > > On Tue, 2016-06-21 at 17:51 +0300, Heikki Krogerus wrote: > > > > +What: /sys/class/typec//supported_data_roles > > > > +Data: June 2016 > > > > +Contact: Heikki Krogerus > > > > +Description: > > > > + Lists the USB data roles, host or device, the port is > > > > capable > > > > + of supporting. > > > > > > On third thought, this is a problem. Looking at 4.4.8.1 > > > DEVICE_CAPABILITIES (Required) of USB Type-C Port Controller > > > Interface Specification we lack capability. > > > > > > A port that can do DRP is not the same thing as a port that > > > can be switched between DFP and UFP. We cannot express that. > > > > What do you mean? DRP means we support and are able to swap the data > > No. That is the error. We support them concurrently. And that is not > obvious. It is perfectly possible to support both but not concurrently. > > > role, but it just does not mean we can act as both source and sink. And > > that information we already get from separate attribute: > > "supported_power_roles". > > But it is different. Suppose we have a port that can be switched between > UFP and DFP, as the spec defines. If it is switched to DFP and we plug > in a DFP it will not work. UFP into UFP has the same result. > > Plugging it into a DRP will always work. > > It is true that both support host and device, but the capability of > the ports is different. And that is not expressed. Sorry but I don't think I understand? So if we can act only as UFP, the supported_data_roles will list: device If we can act only as DFP, the supported_data_roles will list: host If our port is DRD (which would be DRP in the port controller spec), the supported_power_roles will list: device, host And the power role, if the port is Source only, the supported_power_roles will list: source If the port is Sink only, the supported_power_roles will list: sink If our port is DRP, the supported_power_roles will list: source, sink What is there that is missing? We are able to express all the types of "Roles Supported" that the DEVICE_CAPABILITIES define, no? Thanks, -- heikki