Transport Bus Driver FAQ
The following are common questions, scenarions, and issues that a driver developer may encounter when developing a bus driver to support Bluetooth functionality.
My serial bus driver encountered some error. What does it mean?
Code 10-49: An explanation of error codes generated by Device Manager.
Code 51: When a serial bus driver has dependent controller drivers (as defined in the ACPI table), the system will load the serial bus driver, but it will not get started until all of its dependent drivers have started successfully. When the controller driver is absent or not loaded successfully, a code 51 error is triggered.
Code 52 = Unsigned driver.
Driver signing is described in greater detail in these topics:
Why is my serial bus driver not getting any IOCTLs from the Bluetooth core stack?
A serial bus driver may have enabled idle capabilities but not implemented the power control handling mechanisms discussed in section and its subtopics. In this situation, a Bluetooth HID device (mouse or keyboard) will not be able to wake the stack (from D2 to D0). It is recommended to turn off this idle capability until basic Bluetooth functions and power control handling mechanisms have been implemented.
Are there Bluetooth Windows Logo Tests?
The Windows HCK (Hardware Certification Kit) contains a set of Bluetooth-specific tests that must be passed to receive certification. Bluetooth driver developers should run these tests during development to ensure their driver passes them in order to receive certification and have proper support.
Should UART settings be preserved and restored among the different power state transitions?
Since the Bluetooth transport driver is aware of and has control over the remote UART controller’s settings (including its settings after powering on), the Bluetooth transport driver should reset both the remote and local UART controllers before entering a state in which power could be lost. Thus, when power is restored, the settings on both the remote UART (Bluetooth side) and the local UART (Host side) controllers can be in sync. The UART driver has control over the local UART controller only and will be responsible to restore to its settings before powering off. The Bluetooth transport driver can also query the UART driver regarding its power-up settings (since UART driver set them initially using the ACPI table), cache and set them when entering some Dx state.
What happens if the bus driver receives a wake notification while the stack is in the process of entering D2?
In this situation, the bus driver should complete the D2 transition, and then proceed to the wake mechanism. The serial bus driver is expected to do this synchronization (e.g. it can queue the wake request and start the wake process only after the D2 transition has completed).
How should a bus driver identify its ACPI resource of multiple occurrences, such as multiple GPIOs?
There is no way to tag a resource, GPIO or otherwise. This is why the resource order is important. The device driver should establish a convention (e.g. first GPIO resource to appear in the list is for BT_WAKE and the second one to appear is for HOST_WAKE).