From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756868AbcBRNJX (ORCPT ); Thu, 18 Feb 2016 08:09:23 -0500 Received: from mga11.intel.com ([192.55.52.93]:37520 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756749AbcBRNJV (ORCPT ); Thu, 18 Feb 2016 08:09:21 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,465,1449561600"; d="scan'208";a="888639145" Date: Thu, 18 Feb 2016 15:09:16 +0200 From: Heikki Krogerus To: Oliver Neukum Cc: Felipe Balbi , Mathias Nyman , Greg KH , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [PATCH 1/3] usb: USB Type-C Connector Class Message-ID: <20160218130916.GL1859@kuha.fi.intel.com> References: <1455037283-106479-1-git-send-email-heikki.krogerus@linux.intel.com> <1455037283-106479-2-git-send-email-heikki.krogerus@linux.intel.com> <1455718047.7626.22.camel@suse.com> <20160218084724.GA1859@kuha.fi.intel.com> <1455787308.1384.11.camel@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1455787308.1384.11.camel@suse.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 18, 2016 at 10:21:48AM +0100, Oliver Neukum wrote: > On Thu, 2016-02-18 at 10:47 +0200, Heikki Krogerus wrote: > > Hi, > > > The modes that can actually be selected have to be supported by both > > the connector and the partner, and this is where I'm putting the ball > > on the userspace at the moment. I'm not offering a list of > > "possible_alternate_modes" where I list the combination, but instead > > expect the userspace to be figure out that on it's own. > > > > Do you think we should add "possible_alternate_modes" file? > > No, what do we answer to the DFP if we recieve "Discover SVIDs"? > I don't think that we always should answer with all we physically > can. If, for example, the hardware could do Thunderbolt, but the OS > is not prepared to handle it, we shouldn't offer it. So this is > a policy decision to be made in user space. Hence we need > an API to tell it to the kernel. OK. Makes sense. > > P.S. That reminds me, here's my current draft for the > > Documentation/ABI/. Could you take a look? > > OK > > Here are my comments: > > What: /sys/class/type-c/usbcN/connected > > Connection status of the USB Type-C connector usbcN. "yes" when > connected, otherwise "no". > > Unnecessarily wordy. 0 and 1 would do That works for me. > What: /sys/class/type-c/usbcN/current_data_role > > Again, 0 and 1 would do I disagree with this one. What would 0 mean and what would 1? It would require us to make an agreement about the "index" of the role, which creates a small risk of somebody getting it wrong, but for what purpose? Why couldn't it be human readable "host" or "device" so there is never no confusion about it. > What: /sys/class/type-c/usbcN/partner_alternate_modes > > You should say in which number base the values are given. > > What: /sys/class/type-c/usbcN/partner_type > > That could be combined with "connected" Hmm, so in practice getting rid of "connected" completely.. I guess it's OK. > What: /sys/class/type-c/usbcN/supported_data_roles > > A connector can be both. How is that expressed? "host, device". > What: /sys/class/type-c/usbcN/supported_power_roles > > Again, what if it can do both? "source, sink". So these last two are now listing the values that can be entered to the current_data_role and current_power_role. Thanks, -- heikki