linux-kernel - Re: [RFT PATCH] Revert "power: sequencing: request the WLAN enable GPIO as-is"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241216070554.ym54ozdw45zhveo7@thinkpad>
Date: Mon, 16 Dec 2024 12:35:54 +0530
From: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
To: Stephan Gerhold <stephan.gerhold@...aro.org>
Cc: Bartosz Golaszewski <brgl@...ev.pl>,
	Bjorn Helgaas <bhelgaas@...gle.com>, linux-pm@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [RFT PATCH] Revert "power: sequencing: request the WLAN enable
 GPIO as-is"

On Fri, Dec 13, 2024 at 07:19:34PM +0100, Stephan Gerhold wrote:
> On Tue, Dec 03, 2024 at 03:12:51PM +0100, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
> > 
> > This reverts commit a9aaf1ff88a8cb99a1335c9eb76de637f0cf8c10.
> > 
> > With the changes recently merged into the PCI/pwrctrl/ we now have
> > correct ordering between the pwrseq provider and the PCI-pwrctrl
> > consumers. With that, the pwrseq WCN driver no longer needs to leave the
> > GPIO state as-is and we can remove the workaround.
> > 
> 
> Should probably revert commit d8b762070c3f ("power: sequencing:
> qcom-wcn: set the wlan-enable GPIO to output") as well?
> 
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
> > ---
> >  drivers/power/sequencing/pwrseq-qcom-wcn.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/power/sequencing/pwrseq-qcom-wcn.c b/drivers/power/sequencing/pwrseq-qcom-wcn.c
> > index 682a9beac69eb..bb8c47280b7bc 100644
> > --- a/drivers/power/sequencing/pwrseq-qcom-wcn.c
> > +++ b/drivers/power/sequencing/pwrseq-qcom-wcn.c
> > @@ -379,7 +379,7 @@ static int pwrseq_qcom_wcn_probe(struct platform_device *pdev)
> >  				     "Failed to get the Bluetooth enable GPIO\n");
> >  
> >  	ctx->wlan_gpio = devm_gpiod_get_optional(dev, "wlan-enable",
> > -						 GPIOD_ASIS);
> > +						 GPIOD_OUT_LOW);
> >  	if (IS_ERR(ctx->wlan_gpio))
> >  		return dev_err_probe(dev, PTR_ERR(ctx->wlan_gpio),
> >  				     "Failed to get the WLAN enable GPIO\n");
> > -- 
> > 2.30.2
> > 
> 
> I'm not sure why but applying this patch brings back the error I had
> before. It does seem like setting wlan-enable GPIO happens early enough,
> but maybe some timing is still wrong.
>

There should be no room for timing issue now :/
 
> [   17.132161] <gpiod_set_value_cansleep(ctx->wlan_gpio, 1);>
> [   17.480619] ath12k_pci 0004:01:00.0: of_irq_parse_pci: failed with rc=134
> [   17.491997] ath12k_pci 0004:01:00.0: pci device id mismatch: 0xffff 0x1107
> [   17.492000] ath12k_pci 0004:01:00.0: failed to claim device: -5
> [   17.492075] ath12k_pci 0004:01:00.0: probe with driver ath12k_pci failed with error -5
> 

Are you sure that this is the same error that you noticed before?

> Any ideas/suggestions?
> 

Can you verify that the pwrctrl driver's probe is completed *before* ath12k
driver starting to probe by adding the debug prints in both drivers?

- Mani

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