Re: [PATCH v6 01/11] Bluetooth: hci_qca: Add M.2 Bluetooth device support using pwrseq

[sashiko-bot@kernel.org]

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 <manivannan.sadhasivam@oss.qualcomm.com>

    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.

> 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

[ ... ]

> @@ -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