From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Zhangzhansheng <zhang.zhansheng@h3c.com>
Cc: Ladislav Michl <oss-lists@triops.cz>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
Sneeker Yeh <sneeker.yeh@gmail.com>,
Wangxiaoqing <wangxiaoqing@h3c.com>,
Xinhaining <xinhaining@h3c.com>
Subject: Re: [Consulting about: whether the usb "hub workqueue" has concurrency]
Date: Tue, 19 Mar 2024 13:46:58 +0200 [thread overview]
Message-ID: <3818bd2d-2785-76fa-6dc0-8ebf140c2969@linux.intel.com> (raw)
In-Reply-To: <048702a6438a4bcc87c829ccce599826@h3c.com>
On 16.3.2024 5.52, Zhangzhansheng wrote:
> Mathias:
>
> I am so sorry to trouble you again.
>
> The kernel version is 6.7, I recently am confused with the schedule mechanism of usb hub workqueue scheduling mechanism.
>
> When inserting one KingSton USB3.0 U disk in the host, one workA: “hub_event “had been waken up and the work is corresponding to USB3.0 RootHUB.
> But during the initialization of the KingSton USB3.0 U disk, owing to firstly reading device descriptor timeout, then it disabled the
> USB3.0 RootHUB port which bringing up that the USB3.0 RootHUB port switched to USB2.0 RootHUB port. Then I found that another one workB using the
> same callback function of hub_event is initializing one USB full speed device. And the work of workB is one USB2.0 RootHUB.
> However, the workA has not been completed, another workB has been dispatched. The workA and workB uses the same callback function”hub_event” and different work:
> The work of workA is the pointer address of USB3.0 RootHUB, the work of workB is the pointer address of USB2.0 RootHUB.
>
> Based on the above phenomenon analysis, I think that workA and workB has the existence of concurrency, am I right?
> Creating the Hub workqueue, the flags is WQ_FREEZABLE. The code is as follow:
Every hub has a hub_wq workqueue.
USB3 hubs, including USB3 roothubs, are special.
They are both USB2 and USB3 hub devices at the same time.
All other devices are enumerated either as a USB3 or as a USB2 (or slower) device.
If a USB3 device detects USB3 terminations it will enumerate as a USB3 device, and only be
visible for the USB3 hub. In some enumeration failure cases the USB3 device might fall back
to USB2, but will then only appear behind the USB2 hub.
This could be what is going on in your case.
There are some cases where we have to worry about USB2 and USB3 ports concurrency.
for example xHC hosts can't address more than one device at a time even if they are
behind different hubs. For this we have the hcd->address0_mutex. Then there is
some port power control that may affect both the USB2 and USB3 side of a connector.
Thanks
Mathias
parent reply other threads:[~2024-03-19 11:45 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <048702a6438a4bcc87c829ccce599826@h3c.com>]
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=3818bd2d-2785-76fa-6dc0-8ebf140c2969@linux.intel.com \
--to=mathias.nyman@linux.intel.com \
--cc=linux-usb@vger.kernel.org \
--cc=oss-lists@triops.cz \
--cc=sneeker.yeh@gmail.com \
--cc=wangxiaoqing@h3c.com \
--cc=xinhaining@h3c.com \
--cc=zhang.zhansheng@h3c.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.