Re: [PATCH 12/12] Bluetooth: hci_qca: Fix the broken BT_EN GPIO detection for Qcom WCN devices

[Manivannan Sadhasivam]

On Thu, May 07, 2026 at 09:55:16AM -0500, Bartosz Golaszewski wrote:
> 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?
> 

But if fw_devlink is disabled, then the consumer drivers cannot rely on this API
to decide whether power sequencing is required or not. IOW, the error handling
would be broken in consumer drivers if fw_devlink is not enabled.

- Mani

-- 
மணிவண்ணன் சதாசிவம்