docs: draft the upstream escalations

A linux-arm-msm report for the QLINK modem crash (the error string appears nowhere public), and a Fedora kernel-ark MR plus Bugzilla text for enabling SND_SOC_WSA881X. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011XgGF5wfxLDAybVnNz6eNQ
2026-07-28 12:02:19 +03:00
parent 7585c5f147
commit 0ad478e42e
2 changed files with 200 additions and 0 deletions
--- a/docs/drafts/fedora-wsa881x-request.md
+++ b/docs/drafts/fedora-wsa881x-request.md
@@ -0,0 +1,100 @@
+# Draft: Fedora request to enable CONFIG_SND_SOC_WSA881X
+
+Two routes; the merge request is the one that actually changes the
+config, the bug is the paper trail. Doing both is normal: file the bug,
+open the MR, and link them to each other.
+
+## Route 1: kernel-ark merge request (preferred)
+
+Repo: <https://gitlab.com/cki-project/kernel-ark>, branch `os-build`.
+
+The current state, verified 2026-07-28:
+
+- `redhat/configs/common/generic/CONFIG_SND_SOC_WSA881X` contains
+  `# CONFIG_SND_SOC_WSA881X is not set`
+- `redhat/configs/fedora/generic/CONFIG_SND_SOC_WSA883X` contains
+  `CONFIG_SND_SOC_WSA883X=m` (the Fedora override pattern to copy)
+
+The change is one new file:
+
+```
+echo 'CONFIG_SND_SOC_WSA881X=m' > redhat/configs/fedora/generic/CONFIG_SND_SOC_WSA881X
+```
+
+Suggested commit message / MR description:
+
+---
+
+redhat/configs: fedora: enable SND_SOC_WSA881X
+
+The WSA881x is the SoundWire speaker amplifier used on Qualcomm
+SDM845/SDM850 machines. The in-tree sdm850-lenovo-yoga-c630.dts
+(shipped and booted by Fedora's aarch64 kernel-core) names two WSA881x
+devices as codec DAIs of its "SLIM Playback" link, so with the driver
+absent the machine driver defers forever with
+
+  platform sound: deferred probe pending: msm-snd-sdm845:
+      SLIM Playback: codec dai not found
+
+and the sound card never registers. Every other link in the chain is
+already enabled (MFD_WCD934X, SND_SOC_WCD934X, GPIO_WCD934X,
+SOUNDWIRE_QCOM, SND_SOC_SDM845, SLIM_QCOM_NGD_CTRL, QCOM_APR,
+QCOM_PD_MAPPER are all =m), as are the newer members of the same
+driver family, SND_SOC_WSA883X and SND_SOC_WSA884X, which the ThinkPad
+X13s uses.
+
+Verified on a Lenovo Yoga C630 13Q50 (81JL) on 7.1.5-200.fc44.aarch64:
+with snd-soc-wsa881x built out of tree and installed, the
+Lenovo-YOGA-C630-13Q50 card registers, jack detection works, and the
+speaker path plays (UCM profile has been in alsa-ucm-conf since 2020).
+Without it, no sound card has ever registered on this machine on any
+Fedora release.
+
+---
+
+## Route 2: Bugzilla
+
+<https://bugzilla.redhat.com> — Product: Fedora, Component: kernel,
+Version: 44. Severity low, it is a feature enablement.
+
+Summary:
+
+    aarch64: CONFIG_SND_SOC_WSA881X not set; audio cannot work on
+    Lenovo Yoga C630 (SDM850)
+
+Description:
+
+---
+
+Fedora's aarch64 kernel has never enabled CONFIG_SND_SOC_WSA881X, the
+driver for the WSA881x SoundWire speaker amplifier used on Qualcomm
+SDM845/SDM850 hardware. The in-tree device tree
+arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts — which Fedora
+ships in kernel-core and which boots Fedora on this laptop — requires
+two WSA881x DAIs on its "SLIM Playback" link, so the sound card is
+stuck in deferred probe on every Fedora release:
+
+  platform sound: deferred probe pending: msm-snd-sdm845:
+      SLIM Playback: codec dai not found
+
+Everything else in the audio chain is already =m: MFD_WCD934X,
+SND_SOC_WCD934X, GPIO_WCD934X, SOUNDWIRE_QCOM, SND_SOC_SDM845,
+SLIM_QCOM_NGD_CTRL, QCOM_APR, QCOM_PD_MAPPER — and notably the newer
+amplifiers in the same family, SND_SOC_WSA883X=m and
+SND_SOC_WSA884X=m (X13s-era), are enabled.
+
+Reproducer / verification, on 7.1.5-200.fc44.aarch64 on a Yoga C630
+13Q50 (81JL): building sound/soc/codecs/wsa881x.c out of tree and
+loading it makes the Lenovo-YOGA-C630-13Q50 card register immediately,
+with working jack detection and speaker playback (the UCM profile has
+shipped in alsa-ucm-conf since 2020). No other change is needed.
+
+Requested change: CONFIG_SND_SOC_WSA881X=m for Fedora, i.e. one file
+in kernel-ark:
+redhat/configs/fedora/generic/CONFIG_SND_SOC_WSA881X containing
+"CONFIG_SND_SOC_WSA881X=m", matching the existing
+fedora/generic/CONFIG_SND_SOC_WSA883X.
+
+kernel-ark MR: <link once opened>
+
+---
--- a/docs/drafts/linux-arm-msm-report.md
+++ b/docs/drafts/linux-arm-msm-report.md
@@ -0,0 +1,100 @@
+# Draft: report to linux-arm-msm
+
+Send as **plain text** (no HTML), wrapped at ~72 columns. Suggested
+recipients:
+
+```
+To: linux-arm-msm@vger.kernel.org
+Cc: linux-remoteproc@vger.kernel.org,
+    ath10k@lists.infradead.org,
+    Bjorn Andersson <andersson@kernel.org>,
+    Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>,
+    Steev Klimaszewski <steev@kali.org>
+Subject: sdm850-lenovo-yoga-c630: mpss dies at RF init ("RF stuck in QLINK start state"), blocking WCN3990 WiFi
+```
+
+---
+
+Hi,
+
+I am trying to get onboard WiFi working on a Lenovo Yoga C630 13Q50
+(81JL, SDM850) with the mainline sdm850-lenovo-yoga-c630.dts. WCN3990
+never comes up because the wlfw QMI service never appears, and that
+traces to the modem: mpss boots and then dies at RF front-end init,
+identically on every firmware and kernel combination I can construct:
+
+  qcom-q6v5-mss 4080000.remoteproc: MBA booted without debug policy, loading mpss
+  remoteproc remoteproc1: remote processor 4080000.remoteproc is now up
+  qcom-q6v5-mss 4080000.remoteproc: fatal error received:
+      rflm_diag_error.cc:361:RFLM@rflm_qlnk.cpp:1087 [3,3]
+      RF stuck in QLINK start state: 0x0 after maximum
+  remoteproc remoteproc1: crash detected in 4080000.remoteproc: type fatal error
+
+The crash lands ~0.4 s after "is now up" and recovery loops every
+~3.4 s. I cannot find this error string reported anywhere public, so
+here is what I have eliminated:
+
+- Firmware version. WOA-Project publishes nine driver-package versions
+  for this machine containing five distinct mba/mpss builds (including
+  a 2018-vintage pair matching this unit's manufacture date and 2019
+  UEFI, 9UCN33WW(V2.06)); the aarch64-laptops copies differ again by
+  checksum. All produce the identical fatal. The _nm ("no modem")
+  variants are rejected earlier (PBL "unexpected status" / MPSS header
+  authentication failed -3), as expected for the wrong SKU.
+
+- Kernel version, at least recently. Fedora 7.1.5 and Fedora 6.12.15
+  crash identically, same DTB.
+
+- Userspace. rmtfs and tqftpserv running (in-kernel qrtr-ns and
+  pd-mapper); wlanmdsp.mbn reachable through tqftpserv's firmware
+  path; the modem's writable TFTP area present. I also reconstructed
+  the full MCFG tree (mcfg_hw + mcfg_sw, 159 files) from the Windows
+  INF TFTP mappings and served it; the modem crashes before requesting
+  any of it.
+
+- Hardware. This unit is an LTE SKU: SIM slot, factory-label IMEI,
+  and the modem worked under Windows on this exact machine.
+
+- clk/pd gating. Booted with clk_ignore_unused pd_ignore_unused
+  throughout.
+
+Storage-side observations from rmtfs -v, in the half-second before the
+fatal: the modem opens /boot/modem_fs1, _fs2, _fsg and _fsc
+successfully, additionally requests two partitions rmtfs does not
+know, /boot/modem_fsg_oem_1 and /boot/modem_fsg_oem_2 (the names
+appear as strings inside qcdsp2850.mbn; nothing in the Windows driver
+cabinets seems to provide them either), allocates its 2 MiB buffer,
+reads a superblock's worth, and dies. modemst1/modemst2 hold valid
+IMGEFS1/IMGEFS2 filesystems; fsg and fsc on this machine are entirely
+blank.
+
+Since QLINK is the SoC<->SDR845 SerDes link, "stuck in start state
+0x0" looks like the transceiver never answering at all, which makes me
+suspect the RF front end is simply not powered under DT boot -- on
+Windows that would be hidden in the PEP tables, and the mainline DTS
+carries nothing for it. But I cannot confirm that from the ACPI dump,
+so before I go further:
+
+1. Does anyone have onboard WiFi working on a C630 (or any SDM850
+   WoA machine) with a >= 6.x kernel, and if so with which mpss
+   firmware? aarch64-laptops ticked WiFi in 2019 on their 5.x branch,
+   but their issue #51 suggests the modem was crash-looping there
+   too, so possibly wlfw simply appeared before the first crash.
+
+2. Is there any known host-side requirement (regulator, GPIO, PDC
+   resource) for the SDR845 on these laptops that the DTS would need
+   to describe?
+
+3. Are the modem_fsg_oem_1/2 requests, and blank fsg/fsc, known
+   quantities on WoA machines?
+
+Happy to run experiments, capture coredumps (the MBA boots without
+debug policy -- is there a usable path to one on production fuses?),
+or test patches; the machine is a development box reachable over a
+USB WiFi dongle, so nothing is at risk.
+
+Full notes, including the elimination evidence:
+https://github.com/<your-repo-or-git-lair-url>
+
+Thanks,
+Rob Thijssen