GUID_DEVICE_RESET_INTERFACE_STANDARD returning STATUS_NOT_SUPPORTED (0xc00000bb)

I’m trying to follow instructions for working with the guid device reset interface standard without much luck.

I handle IRP_MN_QUERY_REMOVE_DEVICE with a pnp_power_callbacks.EvtDeviceQueryRemove callback that returns STATUS_SUCCESS.
I handle IRP_MN_SURPRISE_REMOVAL with a pnp_power_callbacks.EvtDeviceSurpriseRemoval callback.

I’m trying to call DeviceReset as follows:

context->ResetInterface.DeviceReset(
      context->ResetInterface.Context,
      PlatformLevelDeviceReset,
      0,
      NULL);

Any idea why it’d return NOT_SUPPORTED? What am I missing?

Only a few bus drivers support this relatively new interface. What bus is your device on?

It’s on the pci bus

Can we step back for a second? What are you trying to accomplish?

Most times, I’ve found that when people reach for a “bus reset” what they really want isn’t a bus reset, it simply to trigger an unload and restart of their driver. If that’s what you need, there are better ways to do that (Like WdfDeviceSetFailed).

Peter

I have a PCIe device with a particular FPGA. During a firmware update I’d like to avoid a system reset. The update process invalidates config space and something needs done to restore it. I COULD try to save, update, restore like we do in Linux but it’s not as simple in Windows. Was hoping a bus reset could help make this easier if pci.sys can assist.

Did you try FunctionLevelDeviceReset?

I did try FLR. That doesn’t return an error, but also doesn’t result in a satisfactory reset.

So the platform reset is unlikely to work - it probably would have to reset other devices that cannot be reset. FLR is what you want. If that is not getting config space re-evaluated then you might be SOL. If it is your firmware, could you implement a simulated unplug/plug event function?

A long time ago way back at the beginning of this century I worked on a system where we had to convince PNP to re-enumerate pci busses. It was very ugly. It was do-able.

@Mark_Roddy said:
So the platform reset is unlikely to work - it probably would have to reset other devices that cannot be reset. FLR is what you want. If that is not getting config space re-evaluated then you might be SOL. If it is your firmware, could you implement a simulated unplug/plug event function?

Do you mind explaining why FLR is what I actually want, and if FLR isn’t working why platform-level reset is unlikely to work? The device is offered as a standalone PCI card as well, so a firmware implementation would only work for devices when they’re installed in our system.

I was hoping I was simply not meeting the needs of the platform-level reset request, I could fix it, and see if the teardown/rebuild would correct it.

FWIW, in Linux I’m doing a pci_save_state() and pci_restore_state(), but that looks like a rats nest to duplicate in Windows.

So, if I may read between the lines, the issue is not that you need a reset. The issue is that you lose the contents of configuration space during an FPGA reload. Is that it? A reset does absolutely nothing to help that. You need a re-enumeration. That happens at a lower level. If your BIOS supports PCIe hotplug, your device can drop off the bus and re-appear, but few BIOSes do so. In my experience, this requires a reboot. Windows Update does have a “firmware update” path that happens very early in boot, but it’s quite involved, and I’m not even sure it’s exposed outside of Redmond.

@Tim_Roberts said:
So, if I may read between the lines, the issue is not that you need a reset. The issue is that you lose the contents of configuration space during an FPGA reload. Is that it?

Yes.

I’m probably not understanding the documentation properly. My understanding was that a platform-reset would cause my device to report as missing from the bus and pci.sys (in this case) would teardown/rebuild my device satisfactorily. Rebuilding config space is really what needs to occur. My implementation will guarantee config space does change from one release to the next, so a save/restore could work. I’m looking for the laziest most efficient way to do that (without a system reboot). It’s sounding more and more like it’s unavoidable.

If your BIOS supports PCIe hotplug, your device can drop off the bus and re-appear, but few BIOSes do so.
How do you drop off the bus and reappear? That might be something I could evaluate at least for our systems.

Well, PlatformLevelDeviceReset IS what you want. But it’s not clear (at least to me) when/how the PCI Bus Driver will grant it, or if you need specific support for it in your BIOS or your hardware platform.

The Windows docs make it clear that PLDR is accomplished by toggling the power plane to which your device is attached:

The reset operation affects a specific device and all other devices that are connected to it via the same power rail or reset line. This type of reset has the most impact on the system.

Not understanding the constraints the PCI uses, it’d be hard to rely on it to work in arbitrary configurations.

The alternative, as Mr. @Tim_Roberts said, would be to have your DEVICE do its own little reset. Basically, it needs to look like it’s powered off to D3 Cold, wait, and then power itself back on. But (as Mr. Robers also said) it’s not certain that this’ll work on all BIOSes either.

Sorry… I think requiring a reboot after the firmware update is in your future. OR make the firmware update NOT mess up config space… if that’s even feasible. That’s what we did on a project recently.