locked
Needed sample driver for managing two different protocol in a single driver. RRS feed

  • Question

  • Hi all,

        We are doing windows driver development for managing two different protocols (Wifi and Bluetooth). We are having one hardware chip for both wifi and bluetooth. Our chip is able to handle both wifi and bluetooh(coex) simultaneously, that we verified in linux. In windows also we verified both wifi and bluetooth, but coex is not able to do, if miniport initialized, bluetooth part is failed to run. If we are commenting the miniport initialization bluetooth part is running but wifi is not running.

        Both the protocols are able to run in a single driver or not? If possible address me the reference sample driver code on Github.

    Thanks

    Saturday, January 7, 2017 5:41 AM

Answers

  • Either redesign your chip to comply with the multi-function device requirements https://msdn.microsoft.com/en-us/windows/hardware/drivers/multifunction/index or create a bus driver to manage the chip, and enumerate two physical device objects (PDO) one for each protocol.

    If you go the bus driver route, you are going to have to develop new wifi and Bluetooth miniports because in all likelihood much of the actual chip control will need to be done in the bus driver.


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

    Saturday, January 7, 2017 3:22 PM
  • NDIS takes over the driver object, not allowing you to act as Bluetooth miniport at the same time (don alludes to this). there are two solutiosn used here, neither of which have samples as they are vendor specific

    1) write a bus driver as don suggests (you can use the toaster statbus sample as a starting point). each child stack will have a separate miniport driver so, you have 3 drivers total.

    2) the Bluetooth miniport opens the NDIS miniport (two drivers) and the NDIS driver controls the hw and policy, the Bluetooth driver makes requests to the NDIS driver


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

    Monday, January 9, 2017 6:41 AM

All replies

  • Either redesign your chip to comply with the multi-function device requirements https://msdn.microsoft.com/en-us/windows/hardware/drivers/multifunction/index or create a bus driver to manage the chip, and enumerate two physical device objects (PDO) one for each protocol.

    If you go the bus driver route, you are going to have to develop new wifi and Bluetooth miniports because in all likelihood much of the actual chip control will need to be done in the bus driver.


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

    Saturday, January 7, 2017 3:22 PM
  • NDIS takes over the driver object, not allowing you to act as Bluetooth miniport at the same time (don alludes to this). there are two solutiosn used here, neither of which have samples as they are vendor specific

    1) write a bus driver as don suggests (you can use the toaster statbus sample as a starting point). each child stack will have a separate miniport driver so, you have 3 drivers total.

    2) the Bluetooth miniport opens the NDIS miniport (two drivers) and the NDIS driver controls the hw and policy, the Bluetooth driver makes requests to the NDIS driver


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

    Monday, January 9, 2017 6:41 AM