QCLINUX: Bluetooth: support Bluetooth over both USB and UART#364
Open
shuaz-shuai wants to merge 2 commits intoqualcomm-linux:qcom-6.18.yfrom
Open
QCLINUX: Bluetooth: support Bluetooth over both USB and UART#364shuaz-shuai wants to merge 2 commits intoqualcomm-linux:qcom-6.18.yfrom
shuaz-shuai wants to merge 2 commits intoqualcomm-linux:qcom-6.18.yfrom
Conversation
…h USB and UART When Bluetooth supports both USB and UART, the BT UART driver is always loaded, while USB is hot-pluggable. As a result, when Bluetooth is used over USB, the UART driver still be probed and drive BT_EN low, which causes the Bluetooth device on USB to be disconnected. Configure BT_EN as a GPIO hog so that it is controlled by the platform instead of the UART driver, preventing BT over USB from being unintentionally powered down. Link: https://lore.kernel.org/all/20260311090921.1892191-1-shuai.zhang@oss.qualcomm.com/ Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
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. Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
shashim-quic
requested changes
Mar 19, 2026
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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: 4464912