From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757930AbcEFI3V (ORCPT ); Fri, 6 May 2016 04:29:21 -0400 Received: from mga01.intel.com ([192.55.52.88]:8912 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751071AbcEFI3S (ORCPT ); Fri, 6 May 2016 04:29:18 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,586,1455004800"; d="scan'208";a="697679539" Date: Fri, 6 May 2016 11:29:14 +0300 From: Heikki Krogerus To: Guenter Roeck Cc: Felipe Balbi , Greg KH , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Mathias Nyman Subject: Re: [PATCH 0/3] usb: USB Type-C Class and driver for UCSI Message-ID: <20160506082914.GD29820@kuha.fi.intel.com> References: <1455037283-106479-1-git-send-email-heikki.krogerus@linux.intel.com> <20160505030544.GA25632@roeck-us.net> <87h9ebistj.fsf@intel.com> <572C5031.50805@roeck-us.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <572C5031.50805@roeck-us.net> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 06, 2016 at 01:05:05AM -0700, Guenter Roeck wrote: > Felipe, > > On 05/05/2016 11:50 PM, Felipe Balbi wrote: > > > > Hi Guenter, > > > > Guenter Roeck writes: > > > On Tue, Feb 09, 2016 at 07:01:20PM +0200, Heikki Krogerus wrote: > > > > Hi, > > > > > > > > The OS, or more precisely the user space, needs to be able to control > > > > a few things regarding USB Type-C ports. The first thing that must be > > > > allowed to be controlled is the data role. USB Type-C ports will > > > > select the data role randomly with DRP ports. When USB PD is > > > > supported, also independent (from data role) power role swapping can > > > > be supported together with Alternate Mode control. > > > > > > > > I'm proposing with this set a Class for the Type-C connectors that > > > > gives the user space control over those things on top of getting basic > > > > details about the USB Type-C connectors and also partners. The details > > > > include the capabilities of the port, the supported data and power > > > > roles, supported accessories (audio and debug), supported Alternate > > > > Modes, USB PD support and of course the type of the partner (USB, Alt > > > > Mode, Accessory or Charger), and more or less the same details about > > > > the partner. > > > > > > > > I'm not considering cables with this Class, and I have deliberately > > > > left out some more technical details, like cable orientation, firstly > > > > because I did not see much use for the user space from knowing that > > > > an secondly because that kind of details are not always available for > > > > example with UCSI. > > > > > > > > So the interface to the user space is kept as simple as I dared to > > > > make it. > > > > > > > > NOTE: In case there is somebody wondering, this is not adding USB PD > > > > support to Linux kernel. This is just about USB Type-C. > > > > > > > > > > Hello Heikki, > > > > > > we have implemented a prototype TCPM (USB Type-C Protocol Manager) > > > software on top of your patch set. It will support TCPCI as well > > > as other USB-C controllers such as FUSB302. The plan is to use > > > this software in systems where no separate controller is available. > > > > > > Is there any chance to advance this patch set ? It would be instrumental > > > to get a unified interface to user space. > > > > A newer version of $subject is already in Greg's queue [1] > > > > [1] https://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next&id=0c1849a8c7af652c92ad0265a7ca5934fd773c69 > > > I am aware of that patch. > > Unfortunately, unlike the original submission, the new patch is not an > infrastructure, it is just a driver supporting Intel's UCSI. Unlike the > original series, it does not provide an infrastructure, and it does not > support other implementations of USB Type-C port management systems. > > In our system, we'll have (at least) three such implementations: > > - TCPM and TCPC implemented in EC and/or microcontrollers. > This is currently implemented and shipping with some Chromebooks. > - TCPM implemented in Linux, interfacing to a standard TCPC, using TCPCI > for TCPM-TCPC communication > This will be needed for systems with no EC and a standard Type-C port > controller. > - TCPM implemented in Linux, interfacing to FUSB302. > This will be needed for systems with no EC, utilizing a FUSB302 > port controller. > > All those fit nicely into the infrastructure provided by the original > patch series, where UCSI was just one possible implementation of a > USB Type-C port management system. > > The original patch series had the tremendous advantage of presenting a > unified ABI to user space. With the new patch, this is no longer the case. > All implementations would be completely separate and thus effectively > guarantee ABI fragmentation (Fairchild's code supporting FUSB302 in Linux > is a good example. The existing implementation of Type-C support in the > Chromebooks mentioned above is another). > > I know there has been a lengthy discussion about the patch set, but I may > have missed the conclusion. Is there some reason to _not_ advance it > that I may have missed ? No, we are still continuing with the class driver. We just descided to split the UCIS into separate driver for now, just because we needed it to be supported fast. But I did mention in the commit message of the UCSI patch that the goal is to merge that into a Type-C framework once it's awailable. Thanks, -- heikki