From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1425829AbcBRJYb (ORCPT ); Thu, 18 Feb 2016 04:24:31 -0500 Received: from mx2.suse.de ([195.135.220.15]:47230 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1425712AbcBRJYY (ORCPT ); Thu, 18 Feb 2016 04:24:24 -0500 Message-ID: <1455787308.1384.11.camel@suse.com> Subject: Re: [PATCH 1/3] usb: USB Type-C Connector Class From: Oliver Neukum To: Heikki Krogerus Cc: Felipe Balbi , Mathias Nyman , Greg KH , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Date: Thu, 18 Feb 2016 10:21:48 +0100 In-Reply-To: <20160218084724.GA1859@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> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > 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 What: /sys/class/type-c/usbcN/current_data_role Again, 0 and 1 would do 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" What: /sys/class/type-c/usbcN/supported_data_roles A connector can be both. How is that expressed? What: /sys/class/type-c/usbcN/supported_power_roles Again, what if it can do both?