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