[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210227162703.GA1429200@rowland.harvard.edu>
Date: Sat, 27 Feb 2021 11:27:03 -0500
From: Alan Stern <stern@...land.harvard.edu>
To: liulongfang <liulongfang@...wei.com>
Cc: gregkh@...uxfoundation.org, mathias.nyman@...el.com,
linux-usb@...r.kernel.org, yisen.zhuang@...wei.com,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] USB:XHCI:Modify XHCI driver for USB2.0 controller
On Sat, Feb 27, 2021 at 11:38:08AM +0800, liulongfang wrote:
> On 2021/2/27 0:30, Alan Stern wrote:
> > On Fri, Feb 26, 2021 at 04:21:37PM +0800, Longfang Liu wrote:
> >> Our current XHCI hardware controller has been customized to only
> >> support USB 2.0 ports. When using the current xhci driver, an xhci
> >> controller device and an ehci controller device will be created
> >> automatically.
> >
> > That sentence makes no sense at all. An EHCI controller device is a
> > piece of hardware. How can an xHCI driver, which is a piece of
> > software, create a piece of hardware?
> >
> > Alan Stern
> > .
> >
> The hardware device is a complete USB3.0 controller,
> but I hope to support a USB2.0-only mode through software configuration.
Even if it only supports USB-2.0 connections, an xHCI controller is
still an xHCI controller. It doesn't magically transform into an EHCI
controller.
You are not creating an EHCI controller device. Rather, you are trying
to restrict an xHCI controller device to make it handle only USB-2.0
connections. If you run lsusb on a system that has an xHCI controller,
you'll see that the controller is bound to two USB buses: a USB-2 bus
and a USB-3 bus. But for both buses, the controller is xHCI -- not
EHCI.
Your patch description is inaccurate.
Alan Stern
Powered by blists - more mailing lists