[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20241216134005.bjmw5vo4hn6fzp34@thinkpad>
Date: Mon, 16 Dec 2024 19:10:05 +0530
From: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: Stephan Gerhold <stephan.gerhold@...aro.org>,
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 Mon, Dec 16, 2024 at 02:36:24PM +0100, Bartosz Golaszewski wrote:
[...]
> > Your hack is making sure that the default state of the GPIO is not changed at
> > all after initializing the controller. So even if the pwrctrl driver probes
> > later, it will try to enable the module by doing,
> > 'gpiod_set_value_cansleep(ctx->wlan_gpio, 1)', which would do nothing to the
> > device state.
> >
> > So the issue is not with the pwrctrl driver but with the controller
> > implementation. Ideally, once the device is removed, the PCIe link should move
> > to Detect state and then to Polling state once the receiver is detected on the
> > lanes. But the DWC and Qcom glue has other logics that prevents the controller
> > from doing so.
> >
> > So until the link down handling is implemented in the controller driver, we need
> > to carry this hack that preserves the GPIO state.
> >
>
> Thanks for the explanation Mani. Regarding this patch: I suggest we
> keep it for now but maybe I'll add a comment saying why it's still
> necessary?
>
Yeah, that makes sense.
- Mani
--
மணிவண்ணன் சதாசிவம்
Powered by blists - more mailing lists