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

[Val Packett]

On 10/9/26 1:40 PM, Loic Poulain wrote:
> Hi Val,
>
> On Thu, Oct 8, 2026 at 12:58 AM Val Packett <val@xxxxxxxxxxxx> 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@xxxxxxxxxx>
> > > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxxxxxxxx>
> > > Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxxxxxxxx>
> > > Signed-off-by: Loic Poulain <loic.poulain@xxxxxxxxxxxxxxxx>
> > > ---
> > >    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