docs: rule out the RF clocks and unclaimed rails, and question the premise

The RPMh CXO buffers that clock the transceivers were the best remaining
host-side theory — rf_clk1 and rf_clk3 have no consumer in the C630 tree and
zero enable votes from Linux, and a transceiver with no reference clock fails
exactly the way this one does. Voting all six on changes nothing. Unclaimed
regulators are out too, and the DSDT has no WWAN enable line to assert.

Also worth recording: aarch64-laptops' published device tree, the basis for
believing onboard WiFi once worked here, marks wifi@18800000 disabled and has
no modem node at all. Their WiFi instructions are headed UNSTABLE. The
regression premise may be wrong, and bracketing cannot test it anyway — neither
a hand-built 5.10 nor Fedora's own 6.1.18 reaches userspace on this machine.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011XgGF5wfxLDAybVnNz6eNQ

docs/firmware.md

@@ -420,21 +420,50 @@ Mainline's `mss_pil` node already carries six of the seven clocks. The seventh,
 holding it enabled with an out-of-tree module before starting the modem
 produces the identical QLINK crash.
 
+The RF reference clocks are the other obvious suspect and also innocent.
+`rf_clk1`, `rf_clk2` and `rf_clk3` are the PMIC CXO buffers that clock the
+transceivers — `clk_summary` shows `rf_clk2` claimed by `18800000.wifi` as
+`cxo_ref_clk_pin`, and `rf_clk1`/`rf_clk3` claimed by nobody, with zero enable
+votes from Linux. A transceiver with no reference clock would fail exactly like
+this. Voting all six on (including the `_ao` variants) from a module, verified
+at 38.4 MHz in `clk_summary`, changes nothing.
+
+Unclaimed regulators are innocent too, though the test is weaker: booting with
+`regulator_ignore_unused` leaves `smps2`, `smps7` and a dozen LDOs still off,
+because nothing ever turned them on — the parameter only prevents Linux from
+disabling rails, it cannot enable what UEFI left off. The ACPI offers no
+candidate either: the DSDT defines exactly one `PowerResource` on this machine,
+`WRST`, and it resets WLAN. There is no WWAN enable or disable line to assert.
+
 The modem's own coredump would settle it, but `/sys/class/remoteproc/*/coredump`
 yields a 124 MB image with none of the firmware's strings in it — production
 fuses, encrypted dump. The strings are plainly visible in `qcdsp2850.mbn`
 itself, so the dump is not simply empty.
 
+#### The premise itself is shaky
+
+The reason to suspect a regression is aarch64-laptops' support table, which
+ticks WiFi for this machine. Their published device tree does not support that
+claim. `misc/lenovo-yoga-c630/laptop-lenovo-yoga-c630.dts` marks
+`wifi@18800000` as `status = "disabled"` and contains **no modem node at all** —
+no `4080000.remoteproc`, no MSS remoteproc of any compatible. Their WiFi
+instructions are headed "UNSTABLE", and their issue #51 records WCN3990
+crash-and-lockup behaviour. So "WiFi worked in 2019" may never have been true
+in the form assumed here, and the modem may simply have never got past RF init
+under Linux on this machine.
+
 #### Kernel bracketing has not been possible
 
-The remaining hypothesis is age: something between the 2019 kernel
-aarch64-laptops used and today. Testing it needs an old kernel that boots here,
-and that has not been achieved. A 5.10.261 build (defconfig plus the SDM845
-platform, UFS, PHY and ext4 support, all verified present in `.config`) reaches
-the EFI stub and dies before userspace — no journal, no console output, with
-`earlycon=efifb` and `arm-smmu.disable_bypass=0` both tried. Fedora's 6.12.15
-does boot, and crashes identically to 7.1.5, so the bracket is currently
-6.12 ≤ broken ≤ 7.1 with nothing older testable.
+Testing the regression theory anyway needs an old kernel that boots here, and
+that has not been achieved. Neither a hand-built 5.10.261 (defconfig plus the
+SDM845 platform, UFS, PHY and ext4, all verified in `.config`) nor Fedora's own
+6.1.18 reaches userspace: both die after the EFI stub with nothing in the
+journal, with `earlycon=efifb`, `keep_bootcon` and `arm-smmu.disable_bypass=0`
+tried, and with the initramfs rebuilt without this repo's dracut config in case
+its forced `phy-qcom-qmp-ufs` was the problem. UFS is present in the 6.1 device
+tree, so that is not the cause. Fedora's 6.12.15 boots and crashes identically
+to 7.1.5, leaving the bracket at 6.12 ≤ broken ≤ 7.1 and nothing older testable
+from the internal disk. Booting an old distro from USB is the remaining way in.
 
 Booting test kernels here is otherwise cheap and safe: add a BLS entry, set
 `next_entry` in the GRUB environment for a one-shot boot, and a power-cycle
@@ -469,6 +498,10 @@ Things that sound like they should help and do not:
 - **`gcc_mss_axis2_clk`.** The one clock Windows enables that mainline does
   not; holding it on changes nothing. See above.
 - **Both `_nm` firmware builds.** Rejected by the boot ROM. See above.
+- **The RPMh RF reference clocks.** `rf_clk1/2/3` voted on explicitly; no
+  change. See above.
+- **`regulator_ignore_unused`.** The unclaimed rails were never on to begin
+  with. See above.
 
 Untried, in rough order of promise: reporting upstream — the error string
 appears nowhere public, and linux-arm-msm (Bjorn Andersson, Dmitry Baryshkov,