[qcom-next][rb1] Bluetooth not working

[sgaud-quic]

Bluetooth not working on rb1 board :
Kernel Version : v7.1-rc4
Branch : qcom-next
Tag : https://github.com/qualcomm-linux/kernel/tree/qcom-next-7.1-rc4-20260527
LAVA Job : https://lava.infra.foundries.io/scheduler/job/234641

[   12.123879] /soc@0/display-subsystem@5e00000/dsi@5e94000: Fixed dependency cycle(s) with /soc@0/display-subsystem@5e00000/display-controller@5e01000
[   12.142436] Bluetooth: Failed to init regulators:-517
[   12.244610] Bluetooth: Failed to init regulators:-517
[   12.264742] msm_dsi 5e94000.dsi: supply refgen not found, using dummy regulator
[   12.325889] Bluetooth: Failed to init regulators:-517

[sgaud-quic]

BT failure is caused due to below commit :
f985b64096cf

Reverting this commit fixes the issue :
Passed LAVA job with revert of this commit : https://lava.infra.foundries.io/scheduler/job/234738

Initial analysis on the issue :

 1. wcn3950-pmu probes at [12.131s] but logs "supply vddch1 not found" — its output regulators (vreg_pmu_io etc.) are not successfully registered
  2. wcn3950-bt calls qca_init_regulators() at [12.193s] — devm_regulator_bulk_get() returns -EPROBE_DEFER (-517) because vreg_pmu_io etc. are not yet available
  3. Probe is retried 8+ times but wcn3950-pmu never registers its outputs → BT permanently fails → no /dev/hci0 → BT_FW_KMD_Service fails
 

[lumag]

Not sure, why the DT parts were picked up before driver parts (or what delayed BT part). Please pick up 9f168e4.

[lumag]

Regarding the analysys.

1. wcn3950-pmu probes at [12.131s] but logs "supply vddch1 not found" — its output regulators (vreg_pmu_io etc.) are not successfully registered

No. It says '[ 11.962021] pwrseq-qcom_wcn wcn3950-pmu: supply vddch1 not found, using dummy regulator'. So, the driver is probed and successfully registers the pwrseq.

2. wcn3950-bt calls qca_init_regulators() at [12.193s] — devm_regulator_bulk_get() returns -EPROBE_DEFER (-517) because vreg_pmu_io etc. are not yet available

And here it is supposed to call into the pwrseq system before trying the regulators.

[sgaud-quic]

Not sure, why the DT parts were picked up before driver parts (or what delayed BT part). Please pick up 9f168e4.

This is present in the tree as it is present from v7.1-rc1

[lumag]

I''ve just tested. Pristine 7.0-rc4 works. So it's either something in the tree or some configuration issue. Please reinstantiate the reverted patch and fix the issue.

root@qcom-armv8a:~# uname -a
Linux qcom-armv8a 7.1.0-rc4 #4632 SMP PREEMPT Thu May 28 12:59:06 EEST 2026 aarch64 GNU/Linux
root@qcom-armv8a:~# dmesg | grep hci0
[    7.230855] Bluetooth: hci0: setting up wcn399x
[    9.733255] Bluetooth: hci0: command 0xfc00 tx timeout
[    9.796073] Bluetooth: hci0: Reading QCA version information failed (-110)
[    9.810196] Bluetooth: hci0: Retry BT power ON:0
[    9.981012] Bluetooth: hci0: QCA Product ID   :0x0000000f
[    9.986508] Bluetooth: hci0: QCA SOC Version  :0x40070120
[    9.992044] Bluetooth: hci0: QCA ROM Version  :0x00000102
[    9.997543] Bluetooth: hci0: QCA Patch Version:0x00000001
[   10.034554] Bluetooth: hci0: QCA controller version 0x01200102
[   10.040576] Bluetooth: hci0: QCA Downloading qca/cmbtfw12.tlv
[   10.487509] Bluetooth: hci0: QCA Downloading qca/cmnv12.bin
[   10.579274] Bluetooth: hci0: QCA setup on UART is completed

[lumag]

Okay, the same config from your tag doesn't work. So, it's something the patches between v7.1-rc4 and the tag.
And the offending commit is ... 3809f96 ("WORKAROUND: power: sequencing: qcom-wcn: skip BT devices without bt-enable GPIO"). You have to revert or fix it.

Shiraz Hashim (@shashim-quic) why are we getting random 'workaround' patches which are not posted, not verified for quality and breaking other platforms?

[shuaz-shuai]

Hi Dmitry Baryshkov (@lumag)

I sincerely apologize for this issue.

You are absolutely right. I submitted this patch prematurely:

1. Due to deadline pressure, I bypassed the proper review process and asked shashim-quic to merge it directly.
2. It was not sufficiently tested — I didn't validate it across affected platforms before sending.
3. I did not fully consider the regression risk on other platforms (e.g. WCN3990 and similar chips that don't have dedicated BT/WLAN enable GPIOs by design).

Going forward, I will:
-Submit a new change to correctly handle cross-platform compatibility

• Run proper validation before resubmitting
• Follow the standard submission process

Once again, I apologize for the issues caused by my mistake.

[lumag]

shuaz-shuai Shiraz Hashim (@shashim-quic)

Now you both can observe the results. Deadline pressure is nonsense. Please in future don't ever skip the validation or other procedures. The patches are expected to be posted upstream and to be reviewed.

Nicolas Dechesne (@ndechesne) Ricardo Salveti (@ricardosalveti)

[sgaud-quic]

Closing issue as BT is now functional on RB1 with latest qcom-next tag : qcom-next-7.1-rc4-20260601