> ----------
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Tim Roberts[SMTP:xxxxx@probo.com]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, September 19, 2007 7:58 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] USB Reset
The word “reset” is overloaded in the USB world. There are some things
I would like to clarify.
As I understand it, IOCTL_INTERNAL_USB_CYCLE_PORT, which is sent by
WdfUsbTargetDeviceCyclePortSynchronously, actually triggers the “reset”
protocol on the USB wire. It is equivalent to an unplug/replug. Is
that correct?
I’ve never tried this one but both docs and headers use the word “simulates” so I’d expect software event only.
My last sad experience with USB enumeration problems shows software events are quite different from hw events and even hw events aren’t the same. The disconnect and reconnect from USB at device side isn’t equivalent to unplug/replug, it is weaker. When OS misses the first one, the second leads to recovery.
URB_FUNCTION_RESET_PIPE, which is sent by
WdfUsbTargetPipeResetSynchronously, is just a software-only request to
the host controller driver, to clear out a stall/halt condition and
allow more traffic. Right?
Not sw-only, it leads to USB traffic. It sends CLEAR_FEATURE(Halt) request to given pipe. URB_FUNCTION_ABORT_PIPE is software-only (and very useful sometimes).
So what does IOCTL_INTERNAL_USB_RESET_PORT
(WdfUsbTargetDeviceResetPortSynchronously) do? Does it just do a
RESET_PIPE URB on all of the pipes? Does it affect the USB wire in any way?
It causes USB reset at wire and new descriptors reading. However, instead of real enumeration the device stack isn’t destroyed. I’m not sure how it affects pipes state (I’d expect sw reinitialization) but it doesn’t lead to CLEAR_FEATURE requests.
Try to attach USB analyser and see effects or various IOCTLs. For recovery I use reset pipe and if it doesn’t help, I use reset port.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]