WORKAROUND: QCLINUX: Bluetooth: support Bluetooth over both USB and UART#364
WORKAROUND: QCLINUX: Bluetooth: support Bluetooth over both USB and UART#364shuaz-shuai wants to merge 1 commit intoqualcomm-linux:qcom-6.18.yfrom
Conversation
shashim-quic
left a comment
shashim-quic
left a comment
There was a problem hiding this comment.
QCLINUX: Bluetooth: support Bluetooth over both USB and UART
This is a temporary workaround. Once a proper M.2 binding or solution is upstreamed, both the DTS and driver changes will be reworked and re-submitted according to the M.2 model.
Please prefix it with WORKAROUND , it is so.
shuaz-shuai
force-pushed
the
hamoa_usb_bt_en
branch
from
227eb0c to
a65ea36
Compare
shuaz-shuai
changed the title
The prefix has been added. Please help review. |
sgaud-quic
left a comment
sgaud-quic
left a comment
There was a problem hiding this comment.
Please fix Compilation Issue :
/opt/actions-runner/_work/kernel-config/kernel-config/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts:473.38-488.4: ERROR (phandle_references): /regulator-wcn-bt-en: Reference to non-existent node or label "wcn_bt_en"
https://github.com/qualcomm-linux/kernel-config/actions/runs/23594157895/job/68706519199
This is a temporary workaround. On Hamoa boards, a single M.2 slot may host either a UART-based Bluetooth card or a USB-based Bluetooth card. As a result, the UART controller node is always present in the device tree, while the USB Bluetooth path is hot-pluggable. When Bluetooth is actually used over USB, the hci_qca UART driver still probes due to the DT node being present. During probe and power sequencing, it drives BT_EN low (either directly or via the WCN power sequencer), which can cut power to the shared Bluetooth device and cause the USB Bluetooth interface to disconnect. Model BT_EN as an always-on fixed regulator and ensure that the UART path does not claim power control when BT_EN is not described for that consumer: - Describe BT_EN as a fixed regulator (GPIO 116) that is boot-on and always-on, so it cannot be inadvertently deasserted by the UART probe. - Remove bt-enable-gpios from the WCN7850 power sequencer node and drop its BT pinctrl entry. - Wire the Bluetooth DT supplies to the always-on 3.3V rail so the UART driver can acquire its regulators without depending on the WCN PMU regulators in this dual-path configuration. - Treat WCN7850 like WCN6750/WCN6855 in hci_qca: if no bt_en GPIO is provided for the UART device, disable power control for that instance. - In pwrseq-qcom-wcn, do not match a "bluetooth" consumer if the sequencer has no bt-enable GPIO configured. This prevents the sequencer from binding to a Bluetooth consumer node in the "BT_EN tied high / absent from DT" case and allows the consumer to fall back accordingly. With these changes, probing the UART path no longer deasserts BT_EN when Bluetooth is operating over USB, avoiding unexpected USB disconnects. Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
shuaz-shuai
force-pushed
the
hamoa_usb_bt_en
branch
from
a65ea36 to
24d48e0
Compare
Thanks for the reminder. The update has been completed. |
3 participants
On Hamoa boards, a single M.2 slot may host either a UART-based Bluetooth card or a USB-based Bluetooth card. As a result, the UART controller node is always present in the device tree, while the USB Bluetooth path is hot‑pluggable.
When Bluetooth is actually used over USB, the hci_qca UART driver still probes due to the DT node being present. During probe/power sequencing it drive BT_EN low (either directly or via the WCN power sequencer), which can cut power to the shared Bluetooth device and cause the USB Bluetooth interface to disconnect.
Model BT_EN as an always-on fixed regulator and ensure the UART path does not claim power control when BT_EN is not described for that consumer:
- Describe BT_EN as a fixed regulator (GPIO 116) that is boot-on and
always-on, so it cannot be inadvertently deasserted by the UART probe.
- Remove bt-enable-gpios from the WCN7850 power sequencer node and drop
its BT pinctrl entry.
- Wire the bluetooth DT supplies to the always-on 3.3V rail so the UART
driver can acquire its regulators without depending on the WCN PMU
regulators in this dual-path configuration.
- Treat WCN7850 like WCN6750/WCN6855 in hci_qca: if no bt_en GPIO is
provided for the UART device, disable power control for that instance.
- In pwrseq-qcom-wcn, do not match a "bluetooth" consumer if the
sequencer has no bt-enable GPIO configured. This prevents the sequencer
from binding to a bluetooth consumer node in the "BT_EN tied high /
absent from DT" case and allows the consumer to fall back accordingly.
With these changes, probing the UART path no longer deasserts BT_EN when Bluetooth is operating over USB, avoiding unexpected USB disconnects.
Without this change, Bluetooth over USB does not work.
This is a temporary workaround. Once a proper M.2 binding or solution is upstreamed, both the DTS and driver changes will be reworked and re-submitted according to the M.2 model.
CRs-Fixed: 4480880