negotiating only USB2.0 at the device level in ubuntu
working with claude and manus AI and checking in windows and linux, it is a fact that this device is not supporting USB3.X really.
This is the definitive answer. Same result on a fresh hot-plug: both the storage-mode handshake and the WLAN-mode handshake show new high-speed USB device (480M) at the very first electrical negotiation — this isn't a cold-boot artifact, mode-switch quirk, cable issue, or port issue. The device's USB PHY is genuinely negotiating USB 2.0 High Speed from the first handshake, every time.
So here's the likely real picture: the RTL8852AU chip in this adapter has a USB 2.0 PHY/interface internally — this is common even in "USB 3.0" branded WiFi 6 dongles, because the actual WiFi 6 throughput (even at 80MHz, ~700 Mbps PHY rate translates to maybe 300-400 Mbps real TCP throughput) doesn't strictly require a SuperSpeed link to avoid being the bottleneck. TP-Link's "USB 3.0" marketing and the included SS-marked cable likely refer to compatibility/recommendation (plug into a USB 3.0 port for better power delivery and to avoid bus contention with USB 2.0 hubs) rather than the device actually negotiating a 5 Gbps SuperSpeed link.
This also retroactively explains the Windows "ROOT_HUB30" finding — as I mentioned earlier, that's just the xHCI controller's hub name in Windows' device tree, and doesn't prove the device itself negotiated SuperSpeed. The device is almost certainly running at USB 2.0/480M on Windows too; Windows just doesn't surface that as obviously as lsusb -t does.
Practically: 480 Mbps USB 2.0 gives you roughly 280-350 Mbps real-world throughput, which is in the same ballpark as your actual WiFi throughput ceiling anyway (80MHz HE-MCS7 PHY rate of 720 Mbps rarely translates to more than ~400-500 Mbps real TCP). So this is unlikely to be a meaningful bottleneck for your actual use case — your Wi-Fi link itself (signal, channel width, AP capability) is the more relevant factor.
Want me to update memory marking this as resolved/explained, or is there something else you want to chase here?
You said: so in linux it will always show 2.
so in linux it will always show 2.0 not even maybe a driver fault
5:07 PM
Claude responded: Correct — based on what we've seen, it will always show 2.
Correct — based on what we've seen, it will always show 2.00 in Linux, and it's not a driver fault.
The bcdUSB 2.00 value comes from the device's USB descriptor, which is reported by the hardware itself during enumeration — before any driver (rtw89_8852au or otherwise) even loads. The kernel's USB core handles this raw electrical/protocol negotiation at the xHCI controller level, completely independent of the WiFi driver. Since this happened identically on a fresh hot-plug, with the proper SS-rated cable, on a confirmed 5Gbps-capable port, the conclusion is solid: this adapter's USB interface is electrically/functionally USB 2.0 (480M), and that's simply what the hardware is.
This would be the same on any OS — Linux is just more transparent about showing it via lsusb/dmesg, whereas Windows' device tree naming (ROOT_HUB30) obscures it by referring to the controller rather than the negotiated link speed.
So: not a driver issue, not a Linux-specific limitation, not something to chase further. The adapter is a USB 2.0 device that happens to be marketed/bundled as "USB 3.0 compatible."
