From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758028AbcEFIFW (ORCPT ); Fri, 6 May 2016 04:05:22 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:36880 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751644AbcEFIFS (ORCPT ); Fri, 6 May 2016 04:05:18 -0400 Subject: Re: [PATCH 0/3] usb: USB Type-C Class and driver for UCSI To: Felipe Balbi , Heikki Krogerus References: <1455037283-106479-1-git-send-email-heikki.krogerus@linux.intel.com> <20160505030544.GA25632@roeck-us.net> <87h9ebistj.fsf@intel.com> Cc: Greg KH , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Mathias Nyman From: Guenter Roeck Message-ID: <572C5031.50805@roeck-us.net> Date: Fri, 6 May 2016 01:05:05 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <87h9ebistj.fsf@intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated_sender: linux@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: authenticated_id: linux@roeck-us.net X-Authenticated-Sender: bh-25.webhostbox.net: linux@roeck-us.net X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 ? Thanks, Guenter