On Fri, Jul 4, 2025 at 3:30 PM Shuai Zhang <quic_shuaz@xxxxxxxxxxx> wrote: > > > > On 2025/7/2 18:23, brgl@xxxxxxxx wrote: > > On Mon, 9 Jun 2025 18:55:00 +0800, Shuai Zhang <quic_shuaz@xxxxxxxxxxx> wrote: > >> > >> Some modules have BT_EN enabled via a hardware pull-up, > >> meaning it is not defined in the DTS and is not controlled > >> through the power sequence. In such cases, fall through > >> to follow the legacy flow. > >> > > > > Thanks Stephan for bringing this to my attention. > > > > Shuai: you have not Cc'ed arm-msm or even linux-kernel and so didn't give us > > any chance to object. I will separately send a MAINTAINERS change to add > > arm-msm as the mailing list for this driver. > > > > What is the problem you're seeing? The bt-enable GPIO is optional in the power > > sequencing driver and if it's not there, then there should be no difference in > > how this driver works. What are the offending platforms? > > > > The observed issue is that the Bluetooth driver fails to load, > and bluetoothctl shows the message: "Waiting to connect to bluetoothd..." > > The bt-enable GPIO is optional, but when the power sequence does > not define "bluetooth", it results in an EPROBE_DEFER error, > which causes the Bluetooth driver to be repeatedly reloaded. > We are talking about the bt-enable-gpios property of the pmu node, right? What does it mean that the 'power sequence does not define "bluetooth"'? Is the power sequencing provider not probing correctly? > On the Lemans platform, which uses the BT M.2 interface, the bt_en signal > is pulled up via hardware, so it does not need to be defined in the DTS. > Which lemans are we talking about? arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi has the bt-enable-gpios property. Unfortunately I cannot test it, because the board I have remote access to has been reflashed and became sa8255p-ride instead. Bartosz > >> Signed-off-by: Shuai Zhang <quic_shuaz@xxxxxxxxxxx> > >> --- > >> drivers/bluetooth/hci_qca.c | 13 ++++++++++--- > >> 1 file changed, 10 insertions(+), 3 deletions(-) > >> > >> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c > >> index a2dc39c00..976ec88a0 100644 > >> --- a/drivers/bluetooth/hci_qca.c > >> +++ b/drivers/bluetooth/hci_qca.c > >> @@ -2392,10 +2392,17 @@ static int qca_serdev_probe(struct serdev_device *serdev) > >> */ > >> qcadev->bt_power->pwrseq = devm_pwrseq_get(&serdev->dev, > >> "bluetooth"); > >> - if (IS_ERR(qcadev->bt_power->pwrseq)) > >> - return PTR_ERR(qcadev->bt_power->pwrseq); > >> > >> - break; > >> + /* > >> + * Some modules have BT_EN enabled via a hardware pull-up, > >> + * meaning it is not defined in the DTS and is not controlled > >> + * through the power sequence. In such cases, fall through > >> + * to follow the legacy flow. > >> + */ > >> + if (IS_ERR(qcadev->bt_power->pwrseq)) > >> + qcadev->bt_power->pwrseq = NULL; > >> + else > >> + break; > > > > This is wrong. It just effectively ignores all errors - even -EPROBE_DEFER. > > This patch should be reverted as - depending on the run-time ordering of driver > > probing - it will surely break existing platforms. > > > > Thank you for your reminder. I will update the patch to add handling for > errors and retain the handling for undefined cases. > > >> } > >> fallthrough; > >> case QCA_WCN3950: > >> -- > >> 2.34.1 > > > > Bart >
