Better support of HCD root hub on Windows on ARM

[mcuee]

From: #1046

Side note: [ 0.062403] [00008694] libusb: warning [enumerate_hcd_root_hub] could not infer VID/PID of HCD root hub from 'ACPI\QCOM04A6\2' suggests to me that this is expecting the PCI VID/PID string format that has been common for peripherals on x86_64 and IA32 systems for at least a decade. As I understand it it's not actually a standard--and so, painful on a few different levels, though it's stable so INFs don't need to change--so the parsing will typically fail with ACPI-attached devices like this. While the ACPI table can be tweaked to convince acpi.sys to output almost the classic format (by adding _HW, IIRC--fun story), I think the better solution is, in time, to start to allow for this increasingly common class of device strings.

Good point. We may need to support this kind of HCD root hub better down the road.

Currently the code is like this.
https://github.com/libusb/libusb/blob/master/libusb/os/windows_winusb.c#L1288

if (sscanf(dev_id, "PCI\\VEN_%04hx&DEV_%04hx%*s", &dev->device_descriptor.idVendor, &dev->device_descriptor.idProduct) != 2)
usbi_warn(ctx, "could not infer VID/PID of HCD root hub from '%s'", dev_id);

[tormodvolden]

Is this format described anywhere? In the example above it looks like vendor is QCOM (Qualcomm?) and product could be 0x04A6. To not change our internal structures, if there are not too many vendors we could keep a table of vendor strings and an associated ID, or make a hash out of it, to stuff into our idVendor. I guess any clashes with real USB PCI IDs is not an issue.

[mcuee]

Is this format described anywhere? In the example above it looks like vendor is QCOM (Qualcomm?) and product could be 0x04A6. To not change our internal structures, if there are not too many vendors we could keep a table of vendor strings and an associated ID, or make a hash out of it, to stuff into our idVendor. I guess any clashes with real USB PCI IDs is not an issue.

Unfortunately it does not seem to be documented. Hopefully more people will chime in to see what is shown in their system. The existing Intel/AMD x86/amd64 platform seems to follow the format "PCI\VEN_%04hx&DEV_%04hx%*s". This does not seem to be true for Windows on ARM64.

[mcuee]

Ref:
https://docs.microsoft.com/en-us/windows-hardware/drivers/install/hardware-ids
https://docs.microsoft.com/en-us/windows-hardware/drivers/install/identifiers-for-pci-devices

All PCI/PCIE based USB controller will have the hardware ID which current Windows codes can deal with. The problem is for non PCI/PCIE based USB controller (if there are any such controllers) or if they do not follow the above convention.

There is also a possibility that they are using kind of filter driver and the current Windows code does not work well with this kind of configuration. I found the following from Google.

Qualcomm XHCI Filter Device drivers Hardware IDs:
https://treexy.com/products/driver-fusion/database/universal-serial-bus-controllers/qualcomm/xhci-filter-device/

ACPI\QCOM04A6
ACPI\QCOM0826
URS\QCOM0497&HOST
URS\QCOM0498&HOST
URS\QCOM0897&HOST```

[driver1998]

On my Snapdragon 8cx laptop, the USB Root Hub is indeed below a Qualcomm filter driver (ACPI\QCOM04A6).

My Raspberry Pi 3 and 4 currently doesn't have Windows installed, but on Pi4 the XHCI controller is a PCIe one exposed as an ACPI device in ACPI.

And Pi3 uses a fully custom USB stack with custom host controller driver and root hub driver. It is the case on both Windows IoT Core ARM32 and Desktop ARM64.

For virtual machines, those should just be using standard PCIe USB controllers, just like x86 PCs. (At least QEMU/KVM does)

[sonatique]

Could this PR #1202 help, maybe?

[mcuee]

@sonatique

Indeed I think PR #1202 is an interesting idea.

• windows_winusb libusb_get_device_list: bus numbers are defined and assigned to root hubs directly during the hub pass, by enforcing the defintion of root hub as being a hub without parent. #1202

[tormodvolden]

Can somebody please test #1202 on Windows on ARM?

[mcuee]

@driver1998

Just wondering if you can give #1202 a try on Windows on ARM64?

Pre-built binary for ARM64 Windows.
#1202 (comment)

[mcuee]

@jkunkee

Just wondering if you can give #1202 a try on Windows on ARM64? Thanks.

Pre-built binary for ARM64 Windows.
#1202 (comment)

[mcuee]

Some tests results from @ArminiusTux here in PR #1202.

• windows_winusb libusb_get_device_list: bus numbers are defined and assigned to root hubs directly during the hub pass, by enforcing the defintion of root hub as being a hub without parent. #1202

[sonatique]

@jkunkee

Just wondering if you can give #1202 a try on Windows on ARM64? Thanks.

Pre-built binary for ARM64 Windows. #1202 (comment)

@mcuee : I tested your binary under Windows 11 ARM64 and I got the expected results with testlibusb and listdevs, but I also got expected results when running master (that I compiled for ARM64 by myself).
So I guess I cannot reproduce the original issue, therefore not validating whether #1202 improve something or not in this particular case.

What I mean is that even with current master I am only getting dev_id strings that match the expected "regexp" used by scanf. Therefore my conclusion is that, as opposed to what you said earlier, this format is also valid, in general, under Windows 64.

Now, it might not be valid for all implementations, under ARM64 or not, I don't known

[Droid-MAX]

Droid-MAX/SNANDer#15

Does anyone know what to do with this warning?

[tormodvolden]

Try upgrading to libusb 1.0.27.

[Droid-MAX]

When I updated libusb to version 1.0.27, the program output information about libusb became more.

[Droid-MAX]

I have a vaguely bad feeling about this, could be the next potential supply chain poisoning similar to xz-utils?
And I found that programs built with the libusb-1.0.26 source code at some point in time always output some Libusb-related warning information, which had not been the case before. A warning message appears even after the upgrade to 1.0.27.

[mcuee]

@Droid-MAX

Don't spam the github issues. Thanks.

I have re-opened the relevant issue.

• To downgrade the warning messages related to no DeviceInterfaceGUID registered to info - to debug #1394

If you feel that is not good enough, please open a new issue.