From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754822AbcE3MsJ (ORCPT ); Mon, 30 May 2016 08:48:09 -0400 Received: from mga04.intel.com ([192.55.52.120]:45651 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754087AbcE3MsH (ORCPT ); Mon, 30 May 2016 08:48:07 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,389,1459839600"; d="scan'208";a="711051925" Date: Mon, 30 May 2016 15:48:02 +0300 From: Heikki Krogerus To: Guenter Roeck Cc: Greg KH , Oliver Neukum , Mathias Nyman , Felipe Balbi , Rajaram R , Andy Shevchenko , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [RFC PATCH] usb: typec: Various API updates and fixes Message-ID: <20160530124802.GC20869@kuha.fi.intel.com> References: <1463661894-22820-1-git-send-email-heikki.krogerus@linux.intel.com> <20160525183507.GA23019@roeck-us.net> <20160527075536.GC22411@kuha.fi.intel.com> <57485471.3020505@roeck-us.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57485471.3020505@roeck-us.net> 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 Hi guys, On Fri, May 27, 2016 at 07:06:41AM -0700, Guenter Roeck wrote: > On 05/27/2016 12:55 AM, Heikki Krogerus wrote: > > I'll merge this into any case to v3, and I'll send on Monday. > > > Sounds good. > > Couple of additional comments. > > I don't really know what to do with the 'desc' field in struct typec_mode > for modes received from the partner. I wonder if it makes sense to display > it for partner modes. The idea comes straight from Billboard class where every mode has an index to an _optional_ string. Those desc should ultimately come from the altmode bus driver, and I think never from the port drivers. > Also, there is currently no attribute to show the partner identity (data > received from the Discover Identity command). Would it make sense to add > an 'identity' attribute to the partner device (plus an associated API > function to set it) ? The problem is that we can only use it when the partner and our port are both PD capable. Details about PDUSB devices that are attached are out side the scope of this interface IMO, and need to be in any case handled in USB core by using the PD Class specific descriptors etc., and possible with the help of the future PD stack that you are working on. It's an other task. So this interface IMO should expose only the Type-C specific details about the ports and partners. How about if we just add an attribute "usb_communication_capable" for the partners? That is something that we should be able to always determine, even without USB PD. Thanks, -- heikki