From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755778AbcH3P3X (ORCPT ); Tue, 30 Aug 2016 11:29:23 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:45516 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755601AbcH3P2y (ORCPT ); Tue, 30 Aug 2016 11:28:54 -0400 Date: Tue, 30 Aug 2016 08:28:46 -0700 From: Guenter Roeck To: Heikki Krogerus Cc: Vincent Palatin , Greg KH , Oliver Neukum , Felipe Balbi , Bin Gao , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [PATCHv6 1/3] usb: USB Type-C connector class Message-ID: <20160830152846.GA26785@roeck-us.net> References: <1471867560-93494-2-git-send-email-heikki.krogerus@linux.intel.com> <20160825115958.GE12117@kuha.fi.intel.com> <20160826140710.GG12117@kuha.fi.intel.com> <5f073751-a725-09a2-79be-49709bcd2cf9@roeck-us.net> <20160829134303.GB16924@kuha.fi.intel.com> <20160829140739.GA10151@kuha.fi.intel.com> <20160829185049.GA7316@roeck-us.net> <20160830082227.GB10151@kuha.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160830082227.GB10151@kuha.fi.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Authenticated_sender: guenter@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: authenticated_id: guenter@roeck-us.net X-Authenticated-Sender: bh-25.webhostbox.net: guenter@roeck-us.net X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Heikki, On Tue, Aug 30, 2016 at 11:22:27AM +0300, Heikki Krogerus wrote: > > > > If you are only interested in accessory mode support, maybe we don't need > > the 'type' attribute at all. We could make the 'accessory' attribute always > > visible and display one of "none", "Audio", "Debug", or "Digital Audio". > > It might also make sense to rename the attribute to "accessory_mode". > > That works for me. > > How about if I add the "supports_usb_power_delivery" attribute for the > partners instead to give some details about them. Any objections? > At first glance, the attribute name looks a bit awkward. Let me look into the specification to see what might make sense to report. On top of my head, I don't recall if we are able to report this for a dock which isn't currently connected to power. > > On a side note, while looking into this, I noticed the following: > > > > + if (port->cap->accessory) > > + for (accessory = port->cap->accessory, i = 0; > > + i < port->cap->num_accessory; accessory++, i++) > > + ret += sprintf(buf, "%s\n", > > + typec_accessory_modes[*accessory]); > > > > This means the list of supported accessories always starts with ", ". > > Where does it print ", "? > > I'm not sure what is wrong here, but I'll update this code in any Nothing. Looks like I lost my ability to read code. Somehow the ',' above made it into the string. There is some inconsistency in the output when compared to the other "supported" attributes, though. Here the supported modes are printed in consecutive lines; elsewhere they are printed in a single line with ',' as separator. Thanks, Guenter