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 <linux@xxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
