Anyway to rehook a different EvtInterruptIsr() once after WdfInterruptCreate() is called

Hi

I have bus_driver in which I want to route the child specific interrupts to appropriate child (only).
I followed below to pass the child Isr() func_address to bus_driver
https://blogs.msdn.microsoft.com/doronh/2007/03/07/interfaces-can-contain-both-input-and-output-parametersand-not-just-function-pointers/

But since I have to call WdfInterruptCreate() in bus_Driver PrepHw(), I will not yet have the Child Isr(). Only after bus completes D0Entry() etc, child FDO loads. I could provide a generic top level ISR() in bus_Driver and then route (call only appropriate child ISR()) based on the vector/MsgId. Not much I guess, but this just involves an extra func call.

Rather is there anyway for the bus_Driver to re-hook a different ISR() for the granted vectors? that way, the top-level redirection is done by HW/OS itself.
Also looks like due to my device stack (Net-Adapter), there is not really much I need to do (for this vector) in the Isr()/Dpc(). I just have to mark corresponding SW descriptor(s) as complete/handled. So was thinking of doing (or atleast test) all this in Isr() itself.

It has been discussed before, a bus driver does not have a way to hand off a interrupt to a child device. You have to find a different way to have the child provide the function and a context to call on the interrupt, and the bus driver keeps the ISR and calls the child as needed.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

O.k. Thanks Don.

a bus driver does not have a way to hand off a interrupt to a child device

No way that’s documented, that is.

Consider for a moment that the GPIO Controller Driver hands off his interrupts to GPIO client drivers, through a process called “Second Level Dispatching”; This was introduced in Windows 8… and I’ve been lusting after getting my hands on it ever since.

Peter

GpioClx - Drivers for peripheral devices that send interrupts to general-purpose I/O (GPIO) pins acquire GPIO interrupts as abstract Windows interrupt resources. Kernel-mode driver framework (KMDF) drivers receive these resources through their EvtDevicePrepareHardware event callback functions.

Not sure I understand correctly, But looks like Windows just just provides the resources in abstract (and I am assuming the same contents in a GPIO controller (aka function) driver EvtPrepHW() are in real form), so that coding for a GPIO client KMDF driver isn’t any different from any other KMDF function driver. But still the interrupt goes through controller_Driver and then dispatched by framework to client driver.

It would have been a nice feature, if windows had mechanism to re-hook a different Isr() once after WdfCreareInterrupt is called. That way for certain vectors in case like mine, the child ISR() would be the first/only one invoked directly without any intermediate dispatching.

coding for a GPIO client KMDF driver isn’t any different from any other KMDF function driver

Correct.

still the interrupt goes through controller_Driver and then dispatched by framework to client driver

No. It goes to the controller driver and is the dispatched to the client. The framework is not in any way involved.

In any case, the ability to do what the GPIO controller driver does is not documented or supported. My point was merely that, as of Windows 8, the capability to pass along interrupts exists in Windows… even if we don’t get to play with it.

Peter

O.k. Thanks for the clarification, Peter.