Re: [PATCH 12/12] Bluetooth: hci_qca: Fix the broken BT_EN GPIO detection for Qcom WCN devices
From: Bartosz Golaszewski
Date: Thu May 07 2026 - 11:01:43 EST
On Thu, May 7, 2026 at 1:59 PM Manivannan Sadhasivam <mani@xxxxxxxxxx> wrote:
> >
> > This will break the case of WCN399x devices without the PMU in device
> > tree. There is no enable-gpios since BT is not controllable, but if
> > there is no PMU, then devm_pwrseq_get() will always return
> > -EPROBE_DEFER.
> >
>
> Hmm. I missed that the pwrseq returns -EPROBE_DEFER even if the client doesn't
> require power sequencing. It is because, it has no way to figure it out.
>
> But I think the client can parse the regulator phandle, reach the regulator
> parent, then check for the '-pmu' suffix in the compatible to make sure that it
> has the power sequencing requirement. Then it can call devm_pwrseq_get() only if
> that check passes.
>
I'm wondering if we could maybe provide pwrseq_get_optional() that would only
really be optional with fw_devlink enabled (where we'd be able to ensure the
provider is probed before the consumer thus be able to tell right away if the
device is power-sequenced or not) while with fw_devlink disabled, it would
just behave like pwrseq_get() and return -EPROBE_DEFER?
Would it make sense?
Bart