Re: [PATCH v7 5/8] Bluetooth: hci_qca: Support QCA2066 on M.2 connector via pwrseq

[Val Packett <val@packett.cool>]

On 10/9/26 1:40 PM, Loic Poulain wrote:
> Hi Val,
>
> On Thu, Oct 8, 2026 at 12:58 AM Val Packett <val@packett.cool> wrote:
>>
>> On 10/5/26 9:21 AM, Loic Poulain wrote:
>>> For QCA2066 (and other QCA chips) on M.2 connectors, the UART enable is
>>> controlled by the W_DISABLE2# signal managed by the pcie-m2 power sequencer
>>> rather than a dedicated BT enable GPIO.
>>>
>>> When the serdev controller has an OF graph (indicating it is connected to
>>> an M.2 connector), acquire the 'uart' pwrseq target from the connector's
>>> power sequencer and use it to control BT power instead of the bt-enable
>>> GPIO. This is factored out into qca_serdev_get_m2_pwrseq().
>>>
>>> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
>>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>>> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
>>> ---
>>>    drivers/bluetooth/hci_qca.c | 47 +++++++++++++++++++++++++++++++++++----------
>>>    1 file changed, 37 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
>>> index 1d27ff98034ba99d0783e48db5c605f3b31117ea..b6ec1a57248e2cf4bd138898ffc5cad45b1b4a8b 100644
>>> --- a/drivers/bluetooth/hci_qca.c
>>> +++ b/drivers/bluetooth/hci_qca.c
>>> @@ -1875,6 +1875,9 @@ static int qca_power_on(struct hci_dev *hdev)
>>>                        /* Controller needs time to bootup. */
>>>                        msleep(150);
>>>                }
>>> +
>>> +             if (qcadev->bt_power.pwrseq)
>>> +                     pwrseq_power_on(qcadev->bt_power.pwrseq);
>>>        }
>>>
>>>        clear_bit(QCA_BT_OFF, &qca->flags);
>>> @@ -2396,6 +2399,34 @@ static int qca_init_regulators(struct qca_power *qca,
>>>        return 0;
>>>    }
>>>
>>> +static void qca_serdev_put_pwrseq(void *data)
>>> +{
>>> +     pwrseq_put(data);
>>> +}
>>> +
>>> +static int qca_serdev_get_m2_pwrseq(struct qca_serdev *qcadev)
>>> +{
>>> +     struct serdev_device *serdev = qcadev->serdev_hu.serdev;
>>> +     struct pwrseq_desc *pwrseq;
>>> +
>>> +     if (!of_graph_is_present(dev_of_node(&serdev->ctrl->dev)))
>>> +             return 0;
>> Seems like of_graph_is_present does *not* return false for the existing
>> (non-connector) setup which is currently used in all the laptop device
>> trees..
> If I understand the issue correctly, this can only occur when a UART
> 'port' is left unconnected, in which case the failure is legitimate.
> The laptop device trees should be fixed accordingly, either by
> connecting the port to the corresponding M.2 device or by using the
> usual Bluetooth UART child-node approach. I don't see this issue in
> mainline.

So it looks like this is because commit 014501d141ed ("arm64: dts: qcom: 
hamoa: Add graph port/endpoint anchors to pcie4_port0 and uart14") 
unconditionally added the uart14 endpoint to hamoa.dtsi itself in 
preparation for the future transition to proper M.2 descriptions.

The laptop dts'es themselves still have the older child-node description 
for bluetooth, with a dummy port { uart14_ep: endpoint {}; }; that's not 
used yet.

Could the check be extended to actually verify that there's actually 
something the graph endpoint is connected to? Or should that commit be 
reverted?

Thanks,
~val