From: Manivannan Sadhasivam <mani@kernel.org>
To: Bartosz Golaszewski <brgl@kernel.org>
Cc: "François Roux" <franzelfranzel@gmail.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Krishna Chaitanya Chundru" <krishna.chundru@oss.qualcomm.com>,
linux-pm@vger.kernel.org, linux-pci@vger.kernel.org,
linux-arm-msm@vger.kernel.org, regressions@lists.linux.dev,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v2] power: sequencing: qcom-wcn: power off WLAN at probe
Date: Mon, 12 Oct 2026 21:52:23 +0530 [thread overview]
Message-ID: <as0JBsiiR1T94Adj@debian> (raw)
In-Reply-To: <CAMRc=Mf_szZhsZEB8pmZkGh5pB6AEims68rc1tXE=XGAcMuEvg@mail.gmail.com>
On Tue, Oct 06, 2026 at 11:03:17AM +0300, Bartosz Golaszewski wrote:
> On Sun, 4 Oct 2026 18:51:24 +0200, "François Roux"
> <franzelfranzel@gmail.com> said:
> > The WLAN enable GPIO is requested with GPIOD_ASIS and then kept at its
> > current level, so that a WLAN module left powered on by the firmware is
> > not switched off. The FIXME explains why: toggling it would take the
> > PCIe link down, and the controller driver could not recover from that.
> >
> > That reasoning held while the PCIe link was trained before the
> > sequencer probed. Since commit b921aa3f8dec ("PCI/pwrctrl: Switch to
> > pwrctrl create, power on/off, destroy APIs"), qcom_pcie_host_init()
> > powers the endpoint through pwrctrl before it starts link training, and
> > defers until the pwrctrl driver is bound. That driver cannot bind
> > before this sequencer has probed. Power-on therefore always comes
> > before link training, and keeping the firmware state is now harmful.
> >
> > On the Microsoft Surface Pro 11 (X1E80100), the WCN7850 sits on a
> > PCIe port without a PERST# GPIO. While pci-pwrctrl-pwrseq is not yet
> > bound, the host init is deferred about ten times, and each attempt
> > powers the PHY and controller back down. The later power-on only sets
> > a GPIO that is already high, so the chip is never reset and the link
> > never comes up:
> >
> > qcom-pcie 1c08000.pcie: Device found, but not active
> >
> > The endpoint is not enumerated and ath12k never probes. Bluetooth on
> > the same chip fails too ("QCA Failed to send TLV segment (-110)").
> >
> > Request the GPIO as GPIOD_OUT_LOW. The chip is then off when the
> > sequencer probes, and pwrctrl powers it up cleanly right before link
> > training. Drop the FIXME and the code that preserved the firmware
> > state.
> >
> > Tested on a Surface Pro 11:
> > - b921aa3f8dec plus a one-line version of this change: endpoint
> > enumerated at 2.4 s, ath12k and Bluetooth working.
> > - next-20260929 plus this patch: "PCIe Gen.3 x2 link up" at 3.4 s,
> > ath12k and Bluetooth working, Wi-Fi connected.
> > Without the change, neither kernel enumerates the endpoint.
> >
> > The culprit was found by bisecting v6.17..v7.1, with the DTB and
> > .config held constant.
> >
> > Fixes: b921aa3f8dec ("PCI/pwrctrl: Switch to pwrctrl create, power on/off, destroy APIs")
> > Closes: https://lore.kernel.org/all/CAPjyS8dY0Q_o3XmFjuKZZsjhzhoSNL+ZGJtw5cQt8HiV3sUtxA@mail.gmail.com/
> > Cc: stable@vger.kernel.org
> > Assisted-by: LLM
> > Signed-off-by: François Roux <franzelfranzel@gmail.com>
> > ---
>
> Mani: this looks good to me, any objections to me queuing it for v7.3?
>
No objections from me. As the commit message stated clearly, we no longer need
to rely on firmware configured state.
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
- Mani
--
மணிவண்ணன் சதாசிவம்
next prev parent reply other threads:[~2026-10-12 16:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-04 16:51 [PATCH v2] power: sequencing: qcom-wcn: power off WLAN at probe François Roux
2026-10-06 8:03 ` Bartosz Golaszewski
2026-10-12 16:22 ` Manivannan Sadhasivam [this message]
2026-10-09 16:18 ` Dale Whinham
2026-10-12 13:36 ` Bartosz Golaszewski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=as0JBsiiR1T94Adj@debian \
--to=mani@kernel.org \
--cc=bhelgaas@google.com \
--cc=brgl@kernel.org \
--cc=franzelfranzel@gmail.com \
--cc=krishna.chundru@oss.qualcomm.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=regressions@lists.linux.dev \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox