Hi, > To attempt a work-around and validate the theory I change the > `usb_host_set_config` function (in host-libusb.c) such that it first checks > if the current active configuration matches the request configuration, and > if so skips performing the actual SET CONFIGURATION control transfer.
If libusb is able to correctly report what the current configuration is (i.e. what the kernel has picked at device detection time) then yes, we can do that. And it would probably the best way to tackle the problem as it should not have bad side effects on other devices so we don't need a config option to enable/disable this. > USBDEVFS has support for `USBDEVFS_CLAIM_PORT` (and > `USBDEVFS_RELEASE_PORT`) ioctls. From the definition this seem designed to > limit the interaction that Linux kernel might have with a device on a > claimed port, which seems perfect for this use case. This in fact used in > previous version of qemu if we go back to the host-linux.c days, but with > the change over to host-libusb.c this functionality was lost. > > Was this intentional? The switch to libusb sure. That solves lots of portability issues. Not claiming the port was probably lost because libusb doesn't offer support for that (don't remember all details after years). > Would adding support to host-libusb to use these > ioctl to claim the port be beneficial? I don't feel like side-stepping libusb. That is asking for trouble because usbdevfs might behave differently then and confuse libusb. So, if anything, libusb would need support that, then qemu can use it. > Based on a simple test program and > hardware USB traces for a device connected to a 'claimed' port the kernel > does indeed leave the device in an unconfigured state. (Although it still > performs some basic control transfers to gather descriptor, and strangely > seems to in this case make an explicit SET CONFIGURATION transfer, but sets > configuration to zero, rather than an actual configuration, which, at least > for the devices I was able to test with, avoided the problems of calling > SET CONFIGURATION (1) twice). We could try that too (set config to zero first, then set the config we actually want) and see if that works better. Another option could maybe be a device reset + set config. These two would probably need a config option to enable/disable the quirk though. take care, Gerd
