KMDF: how to get PnP notification on change state of interface created by other driver/device

NTDEV
1

The problem:
There are two KMDF drivers: driverA and driverB. These drivers do not belong to the same driver stack.
The driverA creates device, this device creates interface (using WdfDeviceCreateDeviceInterface()), using specific GUID.
The driverB needs to be notified on each change of the state of this interface, even if it was created before driverB was loaded.
The driverB knows the interface GUID only.


How to do it in WDF/KMDF way?


I found a solution for WDM drivers in this article: Buddy Drivers - Methods for Driver to Driver Communication and it uses IoRegisterPlugPlayNotification() function call for registering notification handler:

status = IoRegisterPlugPlayNotification(
    EventCategoryDeviceInterfaceChange,
    PNPNOTIFY_DEVICE_INTERFACE_INCLUDE_EXISTING_INTERFACES,
    (LPGUID)&GUID_DRIVERA_INTERFACE,
    DeviceObject->DriverObject,
    PlugPlayCallback, DeviceObject,
    &devExt->NotificationEntry);

Is there any WDF equivalent for: `IoRegisterPlugPlayNotification(EventCategoryDeviceInterfaceChange, ...)` ?
2

Why not just use the WDM call (in your WDF driver)?

Peter

3

Good question :slight_smile:
Mainly because I see WDF as a tool that facilitates working on drivers, and I intuitively expect that everything will be easier :slight_smile:
But more seriously, the main difficulty associated with using the IoRegisterPlugPlayNotification() function is that the callback cannot directly open a device - it is necessary to use the WorkItem mechanism. This is not a big problem, but I was hoping that WDF provides an equivalent function without such a limitation.

4

@PiotrG said:
Good question :slight_smile:
Mainly because I see WDF as a tool that facilitates working on drivers, and I intuitively expect that everything will be easier :slight_smile:
But more seriously, the main difficulty associated with using the IoRegisterPlugPlayNotification() function is that the callback cannot directly open a device - it is necessary to use the WorkItem mechanism.

It’s safe to open from within the callback routine as long as the target driver doesn’t trigger synchronous PnP operations from within its IRP_MJ_CREATE/EvtDeviceFileCreate callback. There used to be a case where an inbox driver stack did this (HID maybe?) and the documentation turned that into a generic statement of “don’t do it” (which we also perpetuated for a while)

5

@“Scott_Noone_(OSR)” - thank you for the info, it will be useful for me probably :slight_smile:

6

SWENUM was the driver that caused the doc warning as it enumerated virtual audio/media devices on create. I would have never designed that behavior into HIDClass :).

1 Like