Re: Not enough bandwidth for new device state -- with Etron USB3 controller only

[Alan Stern <stern@rowland.harvard.edu>]

On Thu, Apr 22, 2021 at 01:15:50PM +0200, Greg KH wrote:
> On Thu, Apr 22, 2021 at 04:08:13PM +0500, Roman Mamedov wrote:
> > Hello,
> > 
> > On Thu, 22 Apr 2021 07:49:38 +0200
> > Greg KH <gregkh@linuxfoundation.org> wrote:
> > 
> > > Not a bug, this is how USB works.  Your first hub really does not have
> > > enough bandwidth for that device.  Well, we think it doesn't, the
> > > calculation for that is really really tricky and we error on the side of
> > > "let's not take the risk and just disable the device to be safe".
> > > 
> > > Get a better hub :)
> > 
> > But why the calculation is different when the hub is plugged into the onboard
> > USB 2.0 controller -- and there it works?
> 
> You have more hubs in the way, they take up bandwidth on their own just
> sitting there.
> 
> > I hope you don't take this as a bug report to make it stop working there as
> > well. :)
> > 
> > If it's because the Etron controller is USB 3.0, and the higher speeds are
> > somehow accounted for in the bandwidth calculation, that doesn't seem right,
> > since both of the plugged in downstream hubs are 1.1/2.0-only.
> 
> USB 2 hubs plugged into a USB 3 controller require horrible things to be
> done on the wire to make everything work properly.  Part of that
> horribleness is bandwidth determination that we honestly are not the best
> at in Linux.  But again, we err on the side of safety, which means we
> guess on the low-end compared to other operating systems.

It's even worse in the case of devices plugged into an xHCI controller.  
Those controllers perform bandwidth allocation automatically in 
firmware; the kernel doesn't get any say in the matter.  With EHCI, the 
allocation is all done in software.

Alan Stern