none
DriverDeviceAdd callback in WDF_DRIVER_CONFIG_INIT(&Config, DriverDeviceAdd) is not called after registring the miniport driver. RRS feed

  • Question

  • Hi,

    We are working on networks driver. I want to handle both Wifi and bluetooth drivers in a single code base(Co-existence driver as our hardware supports). is it possible in windows?

    I am trying to register the miniport(WLAN) driver and  parallel to that I want to handle the Bluetooth driver in DriverDeviceAdd callback. But, once miniport is registered, DriverDeviceAdd is not getting called. If I didn't register the miniport then DriverDeviceAdd callback is called for Bluetooth driver. So only one driver is running at a time.

    Could you please any one can help me here to overcome this.

    Thanks,

    Raj.


    Raj kumar Kamsani

    Friday, December 2, 2016 4:43 PM

Answers

  • that is correct. in miniport, wdf expects the "other" port driver (or WDM) to invoke the adddevice routine. unfortunately, you cannot mix and match being a miniport and a full fledged WDF driver in the same driver object as both WDF and the port driver expect to control and initialize the driver object. The design you can use to overcome this is to split the driver into three functional parts

    1)  a bus driver that loads on the hardware device itself. This will enumerate two child devices, one for bluetooth, one for wifi

    2) for bluetooth you can implement the bluetooth "miniport" in the bus driver in the PDO for the bluetooth device. you can also choose to write it as a separate driver that will load on the PDO

    3) for wifi you must write an NDIS miniport as a separate driver. you can choose to make this a full fledged "smart miniport" and implement everything in this driver. Or you can choose to make this a "dump miniport" and pass through each request down the stack to the bus driver and implement the logic in the bus driver (again, you can implement most of the logic in the PDO for the wifi child)


    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Friday, December 2, 2016 6:18 PM

All replies

  • that is correct. in miniport, wdf expects the "other" port driver (or WDM) to invoke the adddevice routine. unfortunately, you cannot mix and match being a miniport and a full fledged WDF driver in the same driver object as both WDF and the port driver expect to control and initialize the driver object. The design you can use to overcome this is to split the driver into three functional parts

    1)  a bus driver that loads on the hardware device itself. This will enumerate two child devices, one for bluetooth, one for wifi

    2) for bluetooth you can implement the bluetooth "miniport" in the bus driver in the PDO for the bluetooth device. you can also choose to write it as a separate driver that will load on the PDO

    3) for wifi you must write an NDIS miniport as a separate driver. you can choose to make this a full fledged "smart miniport" and implement everything in this driver. Or you can choose to make this a "dump miniport" and pass through each request down the stack to the bus driver and implement the logic in the bus driver (again, you can implement most of the logic in the PDO for the wifi child)


    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Friday, December 2, 2016 6:18 PM
  • Thanks Doron for your suggestions. We'll follow this method.

    Raj kumar Kamsani

    Saturday, December 3, 2016 5:01 AM