Phone (2) dead Wi-Fi: I found the actual root cause. It’s the PCIe link, and it’s thermal.
On my unit, the Wi-Fi chip never appears on the PCIe bus. Link training stalls at the very first state, 16 times per boot. Bluetooth works fine, which proves the chip is powered and alive. Warming the phone up made it recover on the first reboot instead of the usual 15–20.
That thermal dependence means it’s a physical contact problem, not software — and it means thepersist / Magisk fix everyone is passing around is aimed at the wrong layer.
This is not a cure. It’s a diagnosis, plus a temporary trick, plus a way for you to get warranty service without being told to do another factory reset.
—
What is actually happening
Everyone has been debugging this at the Android level — toggles, resets, safe mode, flashing. The failure is far below that. Here is my kernel log:
$$
msm_pcie_link_train: PCIe RC0 link initialization failed LTTSM STATE: LTSSM_DETECT_QUIET
cnss: Failed to enable PCIe RC0, err = -1
cnss2: probe of b0000000.qcom,cnss-qca6490 failed with error -1
wlan_pld:pld_register_driver:347:: Fail to register pcie driver
$$
LTSSM_DETECT_QUIET is the first state of the PCIe link training state machine — the point where the host checks whether anything is electrically present on the bus. My phone attempts link training 16 times during boot and never gets past that first state. Not once. It’s not failing speed negotiation. It’s not a handshake problem. The host simply never detects a device on the other end of the wires.
Meanwhile pcie_phy_init: PCIe RC0 PHY is ready! prints on every single attempt — so the PCIe controller inside the Snapdragon is perfectly healthy. The problem is at the other end.
The Bluetooth clue that changes everything
Here’s what nobody seems to have noticed. The QCA6490 is a combo chip: Wi-Fi and Bluetooth are the same piece of silicon. Wi-Fi goes over PCIe; Bluetooth goes over UART. My Bluetooth works perfectly. Watch, earbuds, car audio, every day, for months. And they share power rails. On my device, regulator.45 (pmr735a_s3) explicitly lists both:
$$
consumer:platform:b0000000.qcom,cnss-qca6490 <- Wi-Fi
consumer:platform:soc:bt_qca6490 <- Bluetooth
$$
So: the chip has power. The silicon works. The regulators are delivering voltage. The only thing broken is the PCIe connection itself.
This matters enormously for warranty conversations, because “your motherboard is dead” does not survive contact with a Bluetooth radio that has been working flawlessly the entire time.
The thermal test — this is the part that convinced me
I predicted, before testing, that if this is a marginal solder joint then heating the phone should close it.
Cold (previous attempt, a few days earlier): recovered after roughly 15–20 reboots.
Warmed to 62 °C through normal heavy use, then rebooted: link trained on attempt 1, at 72 °C.
Everything came up at once:
$$
/sys/bus/pci/devices/ 0000:00:00.0 and 0000:01:00.0 <- endpoint finally enumerated
/sys/bus/platform/drivers/cnss2/ b0000000.qcom,cnss-qca6490 <- probe succeeded
lsmod cnss2 … 1 qca6490 <- WLAN module loaded
/dev/wlan crw-rw—- wifi wifi 472, 0 <- the node that was always missing
cmd wifi status connected, 78 Mbps, IP assigned
$$
That /dev/wlan node is the one whose absence causes theFailed to access driver state control param error we’ve all seen in logs. It appears the instant the PCIe link trains.
No software bug responds to board temperature. A device tree error, a corrupt config file, a driver bug, a firmware regression — all of them behave exactly the same at 37 °C and at 72 °C. A physical contact does not.
Check whether your unit has the same fault
Please actually verify this rather than assuming — “dead Wi-Fi” in this thread may not be one single cause, and it would be genuinely useful to know how many of us share this exact signature.
No root needed. Enable USB debugging, plug into a computer with adb, and run:
$$
Should list at least one device. Empty = the chip is not on the PCIe bus.
adb shell ls /sys/bus/pci/devices/
Should show a device bound. Only bind/unbind/module/uevent = probe failed.
adb shell ls /sys/bus/platform/drivers/cnss2/
$$
For the kernel log itself (this works without root — dumpstate runs privileged):
$$
adb bugreport bugreport.zip
$$
Unzip it, open the big .txt, and search for LTSSM. If you see LTSSM_DETECT_QUIET repeated, you have the same fault I do.
Please post your result — build number, whether Bluetooth still works, and how many LTSSMlines you get. If a pattern shows up across units and build versions, that’s much harder for Nothing to keep attributing to individual motherboards.
The temporary trick — and a serious warning first
⚠️ Use only normal heat from using the phone. Games, 4K recording, fast charging, all at once if you want. Never use a hairdryer, a heat gun, an oven, a radiator, or direct sun. Those will destroy your display, swell your battery, and can start a fire. People genuinely do this and ruin their phones. Don’t.
Also understand the trade-off: heat is what closes the joint, but running your phone hot accelerates the metal fatigue that is widening the crack in the first place. Warming it to recover occasionally is fine. Living with a hot phone will shorten whatever life the link has left.
With that said, what worked for me:
Warm the phone with heavy normal use for 10–15 minutes.
Reboot — don’t bother with the Wi-Fi toggle, it does nothing.
Check whether it came back. If not, reboot again.
Once it’s up, do not reboot for any reason. Mine ran four days straight last time.
5.
The reason toggling never works: PCIe link training happens only during boot. Once cnss2 fails its probe, it never retries while the system is running. Rebooting is the only lever any of us has.
Why the persist / Magisk fix cannot work for this
I want to be direct about this, because people are unlocking bootloaders and losing their banking apps over it.
WCNSS_qcom_cfg.ini in /mnt/vendor/persist/wlan/ is read by the WLAN driver after the chip enumerates on PCIe. If your link never trains, the driver never gets far enough to read any file at all. Present, missing or corrupt — it cannot possibly matter.
That also explains why nothing in this thread has ever worked: factory resets, official flashes, EDL. None of them can restore an electrical connection.
If your LTSSM check above shows a healthy link and your fault is elsewhere, then your case is different from mine and persist might be relevant to you. But if you’re stuck at DETECT_QUIET, please don’t unlock your bootloader for this.
Happy to answer questions or help anyone read their own bugreport. And if someone with an unlocked bootloader wants to test whether forcing a manual bind works while the device is warm, that wouldbe an interesting data point, but I would not unlock a daily driver for it.
