Re: [Consulting about: whether the usb "hub workqueue" has concurrency]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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






[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux