From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751897AbcFFN2T (ORCPT ); Mon, 6 Jun 2016 09:28:19 -0400 Received: from mga03.intel.com ([134.134.136.65]:21638 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751293AbcFFN2R (ORCPT ); Mon, 6 Jun 2016 09:28:17 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,427,1459839600"; d="scan'208";a="996164581" Date: Mon, 6 Jun 2016 16:28:08 +0300 From: Heikki Krogerus To: Guenter Roeck Cc: Oliver Neukum , Andy Shevchenko , Rajaram R , Felipe Balbi , Mathias Nyman , Greg KH , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [RFC PATCHv2] usb: USB Type-C Connector Class Message-ID: <20160606132808.GA11617@kuha.fi.intel.com> References: <1463661894-22820-1-git-send-email-heikki.krogerus@linux.intel.com> <1464773169.4051.8.camel@suse.com> <20160601232926.GA8463@roeck-us.net> <20160602101853.GC25305@kuha.fi.intel.com> <20160602161219.GA24772@roeck-us.net> <20160603132140.GB6305@kuha.fi.intel.com> <57518B7A.1030508@roeck-us.net> <20160603151746.GC6305@kuha.fi.intel.com> <20160603183927.GA12659@roeck-us.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160603183927.GA12659@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 On Fri, Jun 03, 2016 at 11:39:27AM -0700, Guenter Roeck wrote: > On Fri, Jun 03, 2016 at 06:17:46PM +0300, Heikki Krogerus wrote: > [ ... ] > > > > > > > > > > In my test case, this gives me > > > > > /sys/class/type-c/usbc0/ > > > > > usbc0.svid:18d1 > > > > > usbc0.svid:18d1/mode0 > > > > > usbc0.svid:18d1/mode0/vdo > > > > > usbc0.svid:18d1/mode0/description > > > > > usbc0.svid:18d1/mode0/active > > > > > ... > > > > > usbc0.svid:ff01 > > > > > usbc0.svid:ff01/mode0/vdo > > > > > usbc0.svid:ff01/mode0/description > > > > > usbc0.svid:ff01/mode0/active > > > > > > Side note: I didn't provide a description/name for the modes, because that > > > would result in something like usbc0.DisplayPort/ instead of usbc0.svid:ff01/, > > > and I prefer a consistent ABI. Since this _is_ part of the ABI, would it make > > > sense to standardize on names for modes in sysfs ? For example, how should > > > a "Display Port" mode directory be named ? It doesn't sound good if I > > > use "usbc0.svid:ff01", someone else uses "usbc0.DisplayPort", and yet > > > someone else uses "usbc0.displayport". > > > > Yeah, let's make them standard. > > > Any name preferences ? I would prefer lower case letters. I don't know the SIDs there are at them moment, other then Display Port. Do you know them? I don't think we can ever guarantee that in every case we will be able to provide a human readable name for the alternate modes if they are vendor defined. We will then potentially still have the names in two different forms: "usbc0.displayport" and "usbc0.svid:xxxx". Is that something acceptable to everybody? I guess if it's not, then to only way to go forward would be to always just use the svid in the name. > > > Also, do we at some point need to standardize the ABI for the standard > > > alternate modes such as DisplayPort (if there are any - again I am not > > > there yet) ? > > > > I don't have an answer to that. > > > Ok, I'll look into it as I proceed with my implementation. > > > > > > > Sounds good to me. Many other subsystems do the same, ie create the subsystem > > > device(s) during registration with the subsystem, so this is in line with other > > > kernel code. > > > > > > Should I send you a follow-up patch on top of yours ? > > > > Sure. I'm a little bit stuck with an other tasks, so let's keep this > > thing rolling. > > > See below. Thanks. I pushed it to my work branch for this class: https://github.com/krohei/linux/commits/typec_class There are still a few open questions, but I'm in any case going to start polishing the driver. I think the other attributes are more or less decided, excluding the alternate modes. Cheers, -- heikki