From: Greg KH <gregkh@linuxfoundation.org>
To: Roman Mamedov <rm@romanrm.net>
Cc: linux-usb@vger.kernel.org
Subject: Re: Not enough bandwidth for new device state -- with Etron USB3 controller only
Date: Thu, 22 Apr 2021 13:15:50 +0200 [thread overview]
Message-ID: <YIFa5uwt0ucgdi0N@kroah.com> (raw)
In-Reply-To: <20210422160813.41e26426@natsu>
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.
thanks,
greg k-h
next prev parent reply other threads:[~2021-04-22 11:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-21 17:37 Not enough bandwidth for new device state -- with Etron USB3 controller only Roman Mamedov
2021-04-22 5:49 ` Greg KH
2021-04-22 11:08 ` Roman Mamedov
2021-04-22 11:15 ` Greg KH [this message]
2021-04-22 14:21 ` Alan Stern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YIFa5uwt0ucgdi0N@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=linux-usb@vger.kernel.org \
--cc=rm@romanrm.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox