From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750974AbcFDCeR (ORCPT ); Fri, 3 Jun 2016 22:34:17 -0400 Received: from mail-pf0-f196.google.com ([209.85.192.196]:36456 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750826AbcFDCeO (ORCPT ); Fri, 3 Jun 2016 22:34:14 -0400 Date: Sat, 4 Jun 2016 10:28:38 +0800 From: Peter Chen To: Lu Baolu Cc: felipe.balbi@linux.intel.com, Mathias Nyman , Greg Kroah-Hartman , Lee Jones , Heikki Krogerus , Liam Girdwood , Mark Brown , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Roger Quadros Subject: Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux Message-ID: <20160604022838.GA26936@shlinux2> References: <1464831449-8973-1-git-send-email-baolu.lu@linux.intel.com> <1464831449-8973-3-git-send-email-baolu.lu@linux.intel.com> <20160603074113.GA30006@shlinux2> <5751AAEE.2090001@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5751AAEE.2090001@linux.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jun 04, 2016 at 12:06:06AM +0800, Lu Baolu wrote: > Hi Peter, > > On 06/03/2016 03:41 PM, Peter Chen wrote: > > On Thu, Jun 02, 2016 at 09:37:24AM +0800, Lu Baolu wrote: > >> > Several Intel platforms implement USB dual role by having completely > >> > separate xHCI and dwc3 IPs in PCH or SOC silicons. These two IPs share > >> > a single USB port. There is another external port mux which controls > >> > where the data lines should go. While the USB controllers are part of > >> > the silicon, the port mux design are platform specific. > >> > > >> > This patch adds the generic code to handle such multiple roles of a > >> > usb port. It exports the necessary interfaces for other components to > >> > register or unregister a usb mux device, and to control its role. > >> > It registers the mux device with sysfs as well, so that users are able > >> > to control the port role from user space. > >> > > >> > Some other archs (e.g. Renesas R-Car gen2 SoCs) need an external mux to > >> > swap usb roles as well. This code could also be leveraged for those archs. > >> > > > Sorry to review this so late, > > It doesn't matter. Thanks for review. Comments are always welcome.:-) > > > from my point,it is a dual-role switch > > driver too, > > No, it's not a dual-role switch driver, but a driver for USB port multiplexing. > > One example of port multiplexing can be found in several Intel SOC and PCH > chips, inside of which, there are two independent USB controllers: host and > device. They might share a single port and this port could be configured to > route the line to one of these two controllers. This patch introduced a generic > framework for port mux drivers. It aids the drivers to handle port mux by > providing interfaces to 1) register/unregister a mux device; 2) lookup the > mux device; and 3) switch the port. > For this case, I can't see it is different with dual-role switch. Your case is just like Renesas case, which uses two different drivers between peripheral and host[1]. > Port multiplexing isn't equal to USB dual role. There are other cases in today's > systems. In several Intel PCH chips, there equips two USB host controllers: ehci > and xhci. The xhci USB2 ports are multiplexed with ehci. This guarantees all > USB ports work even running an old version of OS which lacks of USB3 support. > In theory, we can create a driver for the port mux and switch the ports between > xhci and ehci, but that's silly, isn't it? Why not always USB3?:-) > > Another case is xHCI debug capability. The xHCI host controller might equip > a unit for system debugging (refer to 7.6 of xHCI spec). The debugging unit is > independent of xhci host controller. But it shares its port with xhci. Software > could switch the port between xhci and the debugging unit through the registers > defined in xHCI spec. > Yes, above two are different with dual role switch. But in your code and Kconfig, it seems this framework is dedicated for dual-role. Eg: +menuconfig USB_PORTMUX + bool "USB dual role port MUX support" + help + Generic USB dual role port mux support. I think a general dual role port mux is necessary, it can be used to manage different dual-role switch method, eg - ID pin - External connector through GPIO - SoC register - sysfs - type-C events But this code is better co-work with OTG/Dual-role framework, we'd better have only interface that the user can know which role for the current port. [1] https://lkml.org/lkml/2016/4/7/115 -- Best Regards, Peter Chen