lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 27 Feb 2021 11:27:03 -0500
From:   Alan Stern <>
To:     liulongfang <>
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 

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 

Your patch description is inaccurate.

Alan Stern

Powered by blists - more mailing lists