On Supporting SURPRISE_REMOVAL and STOP in driver

Your usb host controller gets the stop, all devices connected to it get the stop as well


debt from my phone

From: xxxxx@osr.com
Sent: 9/23/2012 7:48 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] On Supporting SURPRISE_REMOVAL and STOP in driver

Hmmmm… This thread started with a discussion about STOP processing. STOP has been historically reserved for resource rebalancing on the PCI bus.

Are there cases in which you can get a STOP on buses other than PCI in Win8? I believe I heard of such a case on SoC-type systems, but the description wasn’t clear and I could be entirely mistaken…


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:

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

This should have been “if you don’t support query-stop.” Sorry.

Jake Oshins
Windows Kernel Team

This message offers no warranties and confers no rights.

“Jake Oshins” wrote in message news:xxxxx@ntdev…

If you don’t support query-remove, then the bus under which your device is
enumerated can’t be stopped. (It’s impossible to prove that you have no
dependencies on it.) And that means that the under which it is enumerated
can’t be stopped. This chaining of failures, even when your device has no
resources, can often mean that hot-plugged devices don’t start.

Jake Oshins
Windows Kernel Team

This message offers no warranties and confers no rights.

wrote in message news:xxxxx@ntdev…

Thank you, Jan and Doron.

Doron: my bad, not QuerySurpriseRemove, just QueryRemove. Thank you for
pointing that out. This is indeed a KMDF driver.

I was actually trying to understand if there could ever be a rebalance of
resources for a driver that does not actually manage any physical devices.
What is the correct/recommended behaviour of a non-core wdf device driver
when it receives the following: QUERY_STOP/STOP and SURPRISE_REMOVE irps ?
Especially when there is no device to remove?

Thank you and Best regards

The distinction between hardware, device firmware and microcode isn’t really
important to spec compliance.

Your D0 IRP arrives at your FDO first, though the contract says you just
forward it down to the lower filters and the bus driver. PCI.sys will
complete the D0 IRP only after the delays have been respected, and after the
rest of spec-defined configuration space has been restored. Then it comes
back to your FDO’s completion routine. At that moment your device should be
in D0.

Jake Oshins
Windows Kernel Team

This message offers no warranties and confers no rights.

“Pavel A” wrote in message news:xxxxx@ntdev…

Thank you for this update, it’s very helpful. Could you clarify one
point here, please?

On 23-Sep-2012 07:46, Jake Oshins wrote:

A similar case will occur if your driver doesn’t respond within the PCI
Express spec timings.

The driver, or hardware/microcode/whatever ?

The spec says that you need to wait 100ms after
bringing up a link before you touch configuration space of an endpoint.
It also says that you have to wait another 100ms after you write a D0
into the PMCSR before you can do anything else to the device. Windows 7
played pretty loose with this stuff, since it didn’t turn buses off at
run time. So I added code to respect these timings.

So, are StartDevice and PnP D0 IRPs sent to driver before or after this
100 ms delay in Win8? Is the driver responsible to wait 100 ms before
accessing the hardware?

– pa

Thanks, everyone ! I appreciate the help given, and I learned something in the process as well.