From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932463AbcBKOB3 (ORCPT ); Thu, 11 Feb 2016 09:01:29 -0500 Received: from mga01.intel.com ([192.55.52.88]:64316 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932081AbcBKOB1 (ORCPT ); Thu, 11 Feb 2016 09:01:27 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,431,1449561600"; d="scan'208";a="650669194" Date: Thu, 11 Feb 2016 15:50:11 +0200 From: Heikki Krogerus To: Greg KH Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Mathias Nyman , Felipe Balbi Subject: Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Message-ID: <20160211135011.GA32213@kuha.fi.intel.com> References: <1455037283-106479-1-git-send-email-heikki.krogerus@linux.intel.com> <1455037283-106479-3-git-send-email-heikki.krogerus@linux.intel.com> <20160209182155.GC31787@kroah.com> <20160210103042.GB5270@kuha.fi.intel.com> <20160210172035.GA28335@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160210172035.GA28335@kroah.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 Hi Greg, > > But surely everybody agrees that decision about the policies regarding > > USB Type-C ports, like which data role to use, do we charge or are we > > letting the other end charge, etc., belongs to the user? > > No, I don't agree. It's still unknown if userspace can react fast > though to these types of "policy" changes. I've heard from some > manufacturers that the response time needed is something that we can't > leave to userspace. There are no restrictions on when role swapping could to be executed or when an alt mode can be entered after the connection is made and an initial role and mode are set. The timing constraints these guys are most likely talking about are related to the USB PD functions that need to be executed, for example DR_Swap when the data role swap is requested and so on. But those are a problem for the drivers that implement the dr_swap, pr_swap and set_alt_mode, or more likely the PD stack, and indeed happen inside kernel. This is probable just a misunderstand. I'm not talking about USB PD Policy, Device Manager, System Policy Manager or anything else USB PD spec defines. Those things will indeed happen inside kernel. My little class is just a high level interface that allows userspace to request kernel to do things which then end up being executed inside kernel. There really should not be any problem here. > And along those lines, do you have a working userspace user of this > interface? We don't create interfaces without a user, especially given > that it takes a long time to ensure that a user/kernel api actually is > correct. We would need to see that to ensure that this kernel > implementation is "correct" and working properly. No users (well, let me get back on this). I want to force peoples hand with this early because, if we exclude details about the cable, which I don't see of any interest to the userspace, the functions and features USB Type-C spec defines are what I'm presenting, and that's it. Unless newer versions of USB Type-C connectors bring something different to the table, the interface is solid. We just need to fine tune it, agree on what are proper names for the files, etc. There is just one function that USB Type-C spec has defined that I have left out of the interface. That is VCONN swapping. I left it out on purpose as it is cable specific, but I'm now thinking about adding that as well. It's not like you have to use it, so why not. > > If you plug > > your phone to your desktop, I would imagine that you want to see the > > phone primarily as the USB device and the desktop as host, and to > > achieve the device role, you don't want to be forced to unplug/replug > > your phone from the desktop until you achieve device role, right? > > Why is unplugging somehow required? Because USB Type-C ports (DRP ones) will select the data role randomly when you connect (to an other DRP port). USB Type-C spec defines that you can "prefer" host mode, but when both ends prefer host mode, it's +-0. Thanks, -- heikki