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

[Manivannan Sadhasivam <mani@kernel.org>]

On Mon, Oct 12, 2026 at 04:10:26PM -0300, Val Packett wrote:
> 
> 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?
> 

Taken care now: https://lore.kernel.org/linux-arm-msm/20261112-hamoa-dt-fix-v1-1-55efbac840f4@oss.qualcomm.com/

I shouldn't have given my r-b tag for the offending patch :/

- Mani

-- 
மணிவண்ணன் சதாசிவம்