Re: [PATCH v6 01/11] Bluetooth: hci_qca: Add M.2 Bluetooth device support using pwrseq
From: sashiko-bot@kernel.org
Date: 2026-09-04 16:02:49
Also in:
linux-pci
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Brittle heuristic for M.2 power sequencer incorrectly assumes any OF graph on the UART controller signifies an M.2 setup, breaking probe on non-M.2 boards.
--
commit af259a50ca6baccd2776acd6a7d13d750b4519f3
Author: Manivannan Sadhasivam [off-list ref]
Bluetooth: hci_qca: Add M.2 Bluetooth device support using pwrseq
This patch adds support for M.2 Bluetooth devices by getting the 'uart'
pwrseq device if an OF graph link is present. This pwrseq device is then used
to control the power supplies of the M.2 card.
quoted hunk ↗ jump to hunk
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index faa964735adb1..c8ea5507bdc2c 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c
[ ... ]
quoted hunk ↗ jump to hunk
@@ -2448,6 +2449,18 @@ static int qca_serdev_probe(struct serdev_device *serdev) case QCA_WCN6750: case QCA_WCN6855: case QCA_WCN7850: + /* + * OF graph link is only present for BT devices attached through + * the M.2 Key E connector. + */ + if (of_graph_is_present(dev_of_node(&serdev->ctrl->dev))) { + qcadev->bt_power->pwrseq = devm_pwrseq_get(&serdev->ctrl->dev, + "uart"); + if (IS_ERR(qcadev->bt_power->pwrseq)) + return PTR_ERR(qcadev->bt_power->pwrseq);
[Severity: High] Does this unconditional error return break probe on non-M.2 boards where the UART controller has an OF graph for other reasons? If the UART controller has an OF graph (port or ports nodes) for something like audio routing or debugger sideband signals, of_graph_is_present() will return true. The driver then unconditionally attempts to acquire a "uart" power sequencer. On non-M.2 boards where this provider does not exist, devm_pwrseq_get() will return -EPROBE_DEFER. Because this path returns the error immediately, it aborts probe and skips the legacy "bluetooth" pwrseq and GPIO initialization, causing the Bluetooth driver to fail to probe on valid, previously supported device trees. The serial.yaml DT binding explicitly allows UART controllers to have both a "bluetooth" child node and port nodes, so this is a valid configuration. (Note: A devres resource leak in this block was successfully fixed later in the series, but this logical heuristic issue appears to remain).
+ break;
+ }
+
if (!device_property_present(&serdev->dev, "enable-gpios")) {
/*
* Backward compatibility with old DT sources. If the-- Sashiko AI review · https://sashiko.dev/#/patchset/20260904-monza-wireless-v6-0-d8c5042b3efd@oss.qualcomm.com?part=1