Can a WDF filter driver intercept hardware interrupts of the underlying functional driver?

milan_durovic

Hi,
I have a situation where an existing PCI device driver receives hardware interrupts for a number of slave devices attached to it (it's a multi-function board). The board has an interrupt status register that indicates which particular slave device requested interrupt. Unfortunately, the existing driver ignores interrupts for a particular slave device I'd like to use and I cannot modify this driver.

I was wondering if WDF would allow me to create a filter driver for the original device and then register my own ISR and the rest of it, that would intercept hardware interrupts and handle the slave device of interest? And if so, would simply returning FALSE from the filter ISR automatically forward further interrupt handling to FDO driver ISR, if I detect that the interrupt received is NOT from my slave device, so that other slave devices are handled as before?

Thanks and regards,
Milan

Doron_Holan

Not possible if there is one interrupt shared across the slave devices. Only one driver can connect the interrupt. There needs to be a private interface the FDO exposes that allows you to share in the processing of the interrupt.

Peter_Viscarola_(OSR)

Good news! Windows does have the built-in capability to do what's called "second level interrupt dispatching" (consider how the GPIO Controller driver distributes interrupts to GPIO Client devices).

Bad news! Windows neither documents nor make this second level interrupt dispatching capability available to driver developers.

Peter

milan_durovic

Thanks guys. It's true, the PCI board has only one hardware interrupt line that is shared among all slave devices. I take your comment @Doron_Holan , but I'm a bit surprised by it - I don't think that this hardware configuration is uncommon.

The PCI device driver is implemented as a bus extender, so IO request handling is done by the slave device drivers, and the main driver creates PDOs for each one. It's just that the interrupt is fully handled by the main device, not slave devices. I have the main driver's source and I thought this approach was wrong in the sense that interrupt handling should really be a part of the slave device driver.

I had a thought that maybe if I somehow put in the PDO slave device description that it requires interrupt resource, I could signal WDF that slave device drivers need to service interrupts, so that forwarding of interrupts from the main device to slave device would happen. The main device driver does get the resource list that includes the interrupt resource, so I thought maybe copying that into PDO of relevant slave device drivers could make the magic happen. But then I thought maybe writing a filter driver that intercepts interrupts could be a simpler option, as the main driver is quite complex.

I'm sure that multi-level interrupt dispatching exists, but maybe WDF designers decided to keep WDF simple, at the expense of not covering some edge cases.

Thanks and regards, Milan

Peter_Viscarola_(OSR)

I don't think that this hardware configuration is uncommon.

It's not unheard of, but it's not common either.

but maybe WDF designers decided to keep WDF simple, at the expense of not covering some edge cases.

Well, that's certainly true... but it doesn't apply in this particular case.

Interrupt handling and resource management mostly aren't WDF things... their Windows things. And second-level interrupt dispatching was added to the OS (in time for Windows 8, IIRC and thus) well after WDF was already implemented, in any case.

I fantasize that SOMEday, the Windows devs will document/expose second-level interrupt dispatching for use by third parties. Yet, in the real world, I just don't even see that happening without a broad-based, specific, need.

Peter