Problem
`BT_FW_KMD_Service` fails on M.2 Key E connector boards with the
M.2 pwrseq support enabled.
The test script checks for static DT compatible strings:
```sh
dt_confirm_node_or_compatible_all
"qcom,wcn3950-bt"
"qcom,wcn7850-bt"
"qcom,wcn6855-bt"
"qcom,wcn6750-bt"
"qcom,bluetooth"
```
On M.2 boards the BT device is dynamically created at runtime by the
`pwrseq-pcie-m2` driver — there is no static `qcom,wcn*-bt` node in the
device tree. The DT only has a `pcie-m2-e-connector` node.
As a result the check logs:
```
[FAIL] DT node/compatible for BT NOT found.
```
even though BT is fully functional:
```
hci0: Type: Primary Bus: UART
BD Address: ... ACL MTU: 1024:7 SCO MTU: 240:8
UP RUNNING
```
Affected platforms(use m.2 solution)
Expected behaviour
The test should pass when BT is operational (hci0 UP RUNNING, HCI present,
firmware loaded), regardless of whether the BT device was described
statically in DT or created dynamically via the M.2 pwrseq driver.
Suggested fix
In `Runner/suites/Connectivity/Bluetooth/BT_FW_KMD_Service/run.sh`,
update the DT check to either:
- Also accept `pcie-m2-e-connector` as a valid indicator that a BT
device may be dynamically present on M.2 boards, or
- Treat this check as a WARN (not FAIL) when HCI is already present
(`/sys/class/bluetooth/hci*` exists and is UP) — HCI presence is
stronger evidence that BT is working than a static DT node lookup.
References
Problem
`BT_FW_KMD_Service` fails on M.2 Key E connector boards with the
M.2 pwrseq support enabled.
The test script checks for static DT compatible strings:
```sh
dt_confirm_node_or_compatible_all
"qcom,wcn3950-bt"
"qcom,wcn7850-bt"
"qcom,wcn6855-bt"
"qcom,wcn6750-bt"
"qcom,bluetooth"
```
On M.2 boards the BT device is dynamically created at runtime by the
`pwrseq-pcie-m2` driver — there is no static `qcom,wcn*-bt` node in the
device tree. The DT only has a `pcie-m2-e-connector` node.
As a result the check logs:
```
[FAIL] DT node/compatible for BT NOT found.
```
even though BT is fully functional:
```
hci0: Type: Primary Bus: UART
BD Address: ... ACL MTU: 1024:7 SCO MTU: 240:8
UP RUNNING
```
Affected platforms(use m.2 solution)
Expected behaviour
The test should pass when BT is operational (hci0 UP RUNNING, HCI present,
firmware loaded), regardless of whether the BT device was described
statically in DT or created dynamically via the M.2 pwrseq driver.
Suggested fix
In `Runner/suites/Connectivity/Bluetooth/BT_FW_KMD_Service/run.sh`,
update the DT check to either:
device may be dynamically present on M.2 boards, or
(`/sys/class/bluetooth/hci*` exists and is UP) — HCI presence is
stronger evidence that BT is working than a static DT node lookup.
References