Re: USB port claiming / set configuration problems

[Gerd Hoffmann]

  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