Best Design to Pass Interrupt from Bus Driver to Child Function Drivers

Hi all,
I'm working on a custom serial driver project, it is KMDF bus/bridge driver for a PCI device that exposes multiple serial com ports. My driver stack is structured as follows:

  • A parent bus driver (FDO) that enumerates and creates child devices(using WdfFdoAddStaticChild) for each serial port.
  • Separate KMDF function driver implements the actual serial port functionality (RX/TX, control lines, etc.). So far I have got Rx/Tx working via polling.

I am trying to dispatch interrupt events (and possibly later other configuration info) from the parent to the child.
The interrupt line is shared across all serial ports and is handled only by the parent (bus) driver. And now I want to implement Rx/Tx using interrupts.

I have tried:

  • Attaching a WDF context to the child PDO in the parent, but could not access in the child function driver
  • Using WdfPdoGetParent( ) but didn't work.
  • Tried passing Interrupt resource (CM_PARTIAL_RESOURCE_DESCRIPTOR) using WdfDeviceAssignProperty but that fails with STATUS_INVALID_PARAMETER.

I am considering trying custom IOCTL's but worried whether it would impact the performance. Also came across Dispatching interrupts to child device drivers from 2007

1)What is the best-practice method to communicate interrupt from a KMDF parent bus driver to its child function drivers?
2)Is using IOCTL-based registration and callbacks from child drivers to the parent FDO a sound and scalable design?
3) Are there better or cleaner alternatives, especially when dealing with many child devices (e.g., 24-42 serial ports)?

Thanks in advance for any guidance or pattern suggestions

I've done this for multiple clients over the years. I used a device interface where the serial driver passed the Interrupt Routine and Context to the bus driver and the bus driver returned the device data and pointers to the routines that provide equivalents for KeAcquireInterruptSpinLock, KeReleaseInterruptSpinLock, and KeSynchronizeExecution. These are direct calls in each direction, so no latency versus IOCTLs.