Content-type: multipart/related; boundary="Boundary_(ID_Vb0JPoc97cUCLLrmxEXMAw)"; type="text/html" --Boundary_(ID_Vb0JPoc97cUCLLrmxEXMAw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable

On Jan 09, 2013, at 11:27 AM, Alan Stern <stern@rowland.ha=> wrote:

On Wed, 9 Jan 2013, Tim Roberts wr= ote:

> Xiaofan Chen wrote:
> > Linux (usbfs)
>= ; > Not supporting forced re-enumeration. But if the kernel sees that t= he
> > device, config, or serial-number string descriptors have = changed, it
> > will automatically re-enumerate the device.
= >
> I heard Alan say that, but I don't understand it. If there = hasn't been
> a re-enumeration, how could the kernel possibly know = that the
> descriptors had changed?

People tend to use wor= ds somewhat carelessly. I do, anyway, and no
doubt many others are ju= st as bad.

So what exactly do you mean by "re-enumeration"?
<= br> In the scenario we were discussing (device reset), what happens is
= basically this: The kernel tells the device's upstream hub to reset the appropriate port. When the reset is complete and the port is enabled, the kernel tells the device to use its old address and then reads the device descriptor, each of the configuration descriptors, and the
s= erial string descriptor. If none of them have changed then whichever
c= onfig and altsettings had been in use before are installed again, and
= that's the end of it.

But if any of those descriptors _has_ chang= ed then the kernel acts as
though the device had been disconnected and= a new device plugged in: It
tells all the relevant drivers that the d= evice is gone, it destroys all
the internal data structures for the de= vice, and then it goes through
the whole initialization and enumeratio= n procedure. This involves a
lot of the same actions as described abov= e: resetting the port,
assigning a new device address, reading the dev= ice descriptor, reading
the config descriptors, and even reading sever= al of the string
descriptors. The difference is that now the descripto= r information
gets used to populate new data structures. In particular= , the
descriptors are parsed -- not just compared against earlier valu= es.
This is somethin= g I could emulate under OSX. Assuming the kernel doesn't just return a cac= hed descriptor instead of sending the request for a device descriptor I co= uld request a descriptor from the device then compare the results against = the ones cached by either libusb or the kernel. If the descriptors have ch= anged darwin_reset_device could then call USBDeviceReenumerate on the devi= ce and return LIBUSB_ERROR_NOT_FOUND to signal that the device is no longe= r available.

This would be consistent with the be= havior under Linux without the need for a new reset abstraction.


= --Boundary_(ID_Vb0JPoc97cUCLLrmxEXMAw)--