hci_transport_h2_libusb: Allow filtering by bus number as well as path.

[jaguilar]

Is your feature request related to a problem? Please describe.
In hci_transport_h2_libusb (and possibly other USB transports?), we currently allow filtering by the port path, but not by the hub number. If there are wireless devices plugged into port 1 of both hub 1 and hub 2, our current filtering mechanics cannot disambiguate between the two.

Describe the solution you'd like
We should add a function like hci_transport_usb_set_hub_and_path or hci_transport_usb_set_hub to hci_transport_usb.h. That function would allow filtering by the hub ID as well as the port path.

The user interface is slightly awkward if we go for a function that only sets the hub ID, since that does not provide enough information to identify a device. So we'd probably want to require hci_transport_usb_set_path to be called if a hub ID is specified. I think probably the version that specifies the hub-and-path would be best.

Describe alternatives you've considered
We could do nothing. Ambiguity would remain.

I'm willing to implement this for the libusb transport. I don't have the easy ability to test that it's working for the other USB transports, so to extend the feature to all of the USB transports someone else would have to help out.

[jaguilar]

(We would use this in the implementation of pybricks/pybricks-micropython#435, but there are probably other use cases.)

[mringwal]

Hi. I wasn't aware that the hub isn't part of the path that we currently use. A new hci_transport_usb_set_hub_and_path() makes sense. I guess we should switch to the linux sysfs naming convention: BUS-PORT.PORT.PORT

hci_transport_usb_set_path isn't implemented for Windows (although it wouldn't hurt) or embedded versions.
If you implement it for libusb, I can test / verify on macOS.

[jaguilar]

I’ll send a pull request later! Thank you for the quick response.

[jaguilar]

#718 got merged.