Hi,
On 02/10/2011 10:31 AM, Peter Stuge wrote:
Hans de Goede wrote:
On 02/10/2011 10:10 AM, Xiaofan Chen wrote:
What if the device "morphs" into another device without changing
the VID/PID?
If the descriptors change, the device will be seen as a new device
too. If the descriptors stay completely the same, then it is seen
as the same device.
I'm not sure this can be relied on. If the device address changes,
then it is in fact a new device, as was discussed in the topology API
thread, and the libusb_device handle is no longer usable.
<linux only>
Right, but the device address does not change from just doing a reset,
unless the descriptors change, quoting the relevant kernel code / doc:
* Do a port reset, reassign the device's address, and establish its
* former operating configuration. If the reset fails, or the device's
* descriptors change from their values before the reset, or the original
* configuration and altsettings cannot be restored, a flag will be set
* telling khubd to pretend the device has been disconnected and then
* re-connected. All drivers will be unbound, and the device will be
* re-enumerated and probed all over again.
Also here is a dmesg, from redirecting a device to a vm using my
redirection code, which uses a libusb with my reset patch, the
device gets redirected and then released again twice:
First time:
[ 8015.642155] gspca: video0 disconnect
[ 8015.653633] gspca: video0 released
[ 8015.952188] usb 2-2: reset full speed USB device using ohci_hcd and address 2
[ 8016.295035] usb 2-2: reset full speed USB device using ohci_hcd and address 2
[ 8022.551271] gspca: probing 093a:2468
[ 8022.556143] pac207: Pixart Sensor ID 0x27 Chips ID 0x08
[ 8022.556152] pac207: Pixart PAC207BCA Image Processor and Control Chip detected (vid/pid 0x093A:0x2468)
[ 8022.562332] input: pac207 as /devices/pci0000:00/0000:00:02.0/usb2/2-2/input/input7
[ 8022.567277] gspca: video0 created
Second time:
[ 8023.754317] gspca: video0 disconnect
[ 8023.767397] gspca: video0 released
[ 8024.138094] usb 2-2: reset full speed USB device using ohci_hcd and address 2
[ 8024.480086] usb 2-2: reset full speed USB device using ohci_hcd and address 2
[ 8026.871235] gspca: probing 093a:2468
[ 8026.875778] pac207: Pixart Sensor ID 0x27 Chips ID 0x08
[ 8026.875787] pac207: Pixart PAC207BCA Image Processor and Control Chip detected (vid/pid 0x093A:0x2468)
[ 8026.881958] input: pac207 as /devices/pci0000:00/0000:00:02.0/usb2/2-2/input/input8
[ 8026.882266] gspca: video0 created
Notice how the device address does not change, also the virtual machine can
talk to the device fine using the same libusb device-handle it got
initially and also used for the resets, iow the device handle stays valid after
the resets.
Now before my patch the gspca driver would re-attach after each reset and I had code
in my redirection code to detach it again after reset, not pretty.
Note that linux (which is also the guest in the vm) does a device reset twice when
enumerating.
</linux only>
>> I'm assuming that the desired behavior is that interfaces claimed
>> before a reset stay claimed over the reset, and that is what my
>> current patch accomplishes. Other systems may need some work to
>> achieve the same result, but I think it is best to define the
>> desired semantics and then try to implement them.
>
> As long as desired semantics are actually possible on all systems,
> because if not then we should maybe do things a little differently,
> so that libusb works the same across platforms.
Agreed. The Mac OS X implementation uses this function:
http://developer.apple.com/library/mac/#documentation/Darwin/Reference/IOKit/IOUSBLib_h/Classes/IOUSBDeviceInterface/index.html#//apple_ref/doc/com/intfm/IOUSBDeviceInterface/ResetDevice
And the documentation states:
"It will not reenumerate the device, which means that the cached device descriptor values will not be updated after the reset.
(If you want the IOUSBFamily to reload the cached values, use the call USBDeviceReEnumerate)."
Which sounds like it does the same as the Linux driver. No idea what it does in case of
a device which morphs with a reset though, the Max OS X implementation may need to
do an explicit USBDeviceReEnumerate, and check for a morph (device changing from
for example a cdrom to an adsl modem) and in case of a morph invalidate the handle
itself.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
