Receive unexpected IOCTL_INTERNAL_USB_RESET_PORT(To be conted)

Sorry for the new thread on the old topic as there seems to be restriction on the amount of posters in a thread (20 ???)

Original Link : http://www.osronline.com/showthread.cfm?link=168546


During the reset port operation, the USB core stack will save off the device configuration and interface settings and restore them after the reset.

Thanks for the suggestion . It possibly becomes the solution in myccgp. Could you help to make it slightly more detailed ?

My understanding is save off the device configuration and interface settings in before forward it to low level and restore them in completion routine if reset is successful.


In some cases unplugging a device on one USB port while there is a bus transaction in progress to a device on another port can cause an electrical signaling glitch which can result in an error being reported for the bus transaction to the device on the other port.

Is it a normal case or an exception caused by HW-related , such as OHCI chipset in Motherbroad ,etc ?

Maybe HW engineer needs to get involved to verify it is the case as you said .

You driver should not need to save the config settings, the usb HC port driver will do that for you

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xiedong_sl@126.com
Sent: Wednesday, October 28, 2009 9:52 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Receive unexpected IOCTL_INTERNAL_USB_RESET_PORT(To be conted)

Sorry for the new thread on the old topic as there seems to be restriction on the amount of posters in a thread (20 ???)

Original Link : http://www.osronline.com/showthread.cfm?link=168546


During the reset port operation, the USB core stack will save off the device configuration and interface settings and restore them after the reset.

Thanks for the suggestion . It possibly becomes the solution in myccgp. Could you help to make it slightly more detailed ?

My understanding is save off the device configuration and interface settings in before forward it to low level and restore them in completion routine if reset is successful.


In some cases unplugging a device on one USB port while there is a bus transaction in progress to a device on another port can cause an electrical signaling glitch which can result in an error being reported for the bus transaction to the device on the other port.

Is it a normal case or an exception caused by HW-related , such as OHCI chipset in Motherbroad ,etc ?

Maybe HW engineer needs to get involved to verify it is the case as you said .


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Got it .

I misunderstand that USBCCGP has the functionality of restoring the settings after reset is done .

If so , then what additional recovery job , in the perspective of Client driver, is needed to make the device work as normal ?

Why I ask this question lies in the fact :

Currently , any request is cancelled after PORT_RESET completes in my function driver. If I discard this unexceptional Reset , the device works well.

Also , Still in the description of IOCTL_INTERNAL_USB_RESET_PORT in MSDN

"A driver can use this request to reset the upstream port of the device it manages. After a successful reset, the bus driver reselects the configuration and… "

Just wanna know what does it mean by “the bus driver” ? ccgp-type driver can be thought of as one ??

Daniel Xie wrote:

Currently , any request is cancelled after PORT_RESET completes in
my function driver. If I discard this unexceptional Reset , the device
works well.

That reminds me. I recall having a similar problem with GET_PORT_STATUS or whatever it is. Passing it down would just hang everything.

Isn’t there some code in [your/my]ccgp that always completes it synchronously with success? You might just take the same approach here as you suggest above. 'course that’s a hack, but…

The reselecting happens not in usbccgp but below it. If you pass down
the reset IOCTL, the config and interfaces will be reselected for you.
The same is true for any client driver.

xiedong_sl@126.com wrote:

Also , Still in the description of IOCTL_INTERNAL_USB_RESET_PORT in MSDN

"A driver can use this request to reset the upstream port of the device it manages. After a successful reset, the bus driver reselects the configuration and… "

Just wanna know what does it mean by “the bus driver” ? ccgp-type driver can be thought of as one ??

>>Isn’t there some code in [your/my]ccgp that always completes it synchronously with success? You might just take the same approach here as you suggest above. 'course that’s a hack, but…

Currently , I can’t evaluate side-effect if simply hacking this request .

At least , if the port does need to be reseted from client driver, then hacking would make it disabled .