Re: [PATCH 1/2] Bluetooth: hci_qca: Add WCN clock management for pwrseq-based power path
From: Yepuri Siddu
Date: Tue Sep 29 2026 - 06:30:51 EST
On 9/29/2026 3:33 PM, Loic Poulain wrote:
On Fri, Sep 25, 2026 at 8:21 AM Yepuri Siddu
<yepuri.siddu@xxxxxxxxxxxxxxxx> wrote:
RPMCC previously kept WCN clocks enabled via proxy votes, so the pwrseq
power path in hci_qca did not need to explicitly manage the clock.
With proxy vote removal, each consumer must explicitly enable and disable
its required clocks.
Extend the pwrseq-based power path to acquire and manage an optional
WCN clock. In qca_serdev_probe(), acquire the clock using
devm_clk_get_optional(). In qca_regulator_enable(), enable the clock
after a successful pwrseq_enable() with proper rollback on failure.
In qca_power_off(), disable the clock before pwrseq_disable().
Targets that do not define a clock in DTS are unaffected since
devm_clk_get_optional() returns NULL and all clock operations are
guarded accordingly.
Signed-off-by: Yepuri Siddu <yepuri.siddu@xxxxxxxxxxxxxxxx>
---
drivers/bluetooth/hci_qca.c | 23 ++++++++++++++++++++---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 7089e9b639b2..489a059e519a 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -2265,6 +2265,8 @@ static void qca_power_off(struct hci_uart *hu)
}
if (power && power->pwrseq) {
+ if (qcadev->susclk)
+ clk_disable_unprepare(qcadev->susclk);
pwrseq_disable(power->pwrseq);
set_bit(QCA_BT_OFF, &qca->flags);
return;
@@ -2324,8 +2326,17 @@ static int qca_regulator_enable(struct qca_serdev *qcadev)
struct qca_power *power = qcadev->bt_power;
int ret;
- if (power->pwrseq)
- return pwrseq_enable(power->pwrseq);
+ if (power->pwrseq) {
+ ret = pwrseq_enable(power->pwrseq);
+ if (ret)
+ return ret;
+ if (qcadev->susclk) {
+ ret = clk_prepare_enable(qcadev->susclk);
Why is susclk guarded by the pwrseq? They seem unrelated to me.
You are right. On further thought, the clock belongs to the WCN hardware
and its power sequencing is already handled by the wcn3988-pmu driver.
So the hci_qca driver does not need to manage it at all.
In v2 we dropped the hci_qca changes and moved the clock property to the
wcn3988-pmu node in DTS instead:
https://lore.kernel.org/all/20260929-bt-wcn-clk-enable-v2-1-7a90902f3df5@xxxxxxxxxxxxxxxx/
Thanks,
Siddu