14. Mainline Linux port readiness — per-subsystem status

Scope note: everything else in this documentation set is reverse engineering — describing what the vendor firmware and hardware actually do, recovered from the dump (and, for a few items, live EDL/adb reads). That work is extensive: every partition has been opened and the boot chain walked stage by stage, though the userspace/hardware inventory, like any such survey, has residual gaps (Open questions and limits of analysis).

A mainline Linux port is a different, much larger piece of forward engineering that this documentation enables but does not replace. This page records, for each hardware block this project identified, what (if anything) already exists upstream versus what does not, checked directly against the mainline source at up to four successively deeper levels of rigor (see Method). It does not rank blocks by priority or declare any of them a target or a non-target — that is a decision for whoever undertakes the port.

14.1. Method

Four checks at increasing depth:

1. Path/filename presence via raw.githubusercontent.com and the GitHub contents API (2026-09-19). Cheap, but path-only — misses a real driver match whose vendor name isn’t in the filename.

2. Full-content grep over a local git clone --depth 1 https://github.com/torvalds/linux /tmp/linux (same day), catching matches pass 1’s path-only check misses (a real wacom_i2c.c, and Parade’s driver living under the historical “cyttsp” filename). Confirms a driver family exists; does not confirm binding.

3. Exact ``compatible`` string diff between this device’s real, extracted board DTB (artifacts/boot_a/board.dts, artifacts/dtbo_a/overlay_0.dts) and the of_device_id/ i2c_device_id tables in the matched mainline driver files (same day). This is the pass that actually answers “would this driver bind to this hardware’s DT node.”

4. Direct disassembly of this vendor’s own compiled driver, for the touch block: the real, currently-running driver is already in this dump (artifacts/kernel, built-in, no separate .ko), so it is disassembled the same way wacom_flash and the FPGA/EPD internals were elsewhere in this project, rather than sourced from an external tree. See the touch entry below and artifacts/re_static/item_touch_pt_core_recheck.txt.

14.2. Per-subsystem status

Block	Status	Detail
SoC core (real chip: SM6350; vendor DTB name: lagoon)	Upstream driver, new DT needed	Real compatible strings in this device’s DTB: qcom,lagoon-gcc, qcom,lagoon-pinctrl, qcom,lagoon-rpmh-clk, etc. — the Qualcomm-internal codename. Mainline’s drivers use the public name: drivers/clk/qcom/gcc-sm6350.c matches "qcom,gcc-sm6350", drivers/pinctrl/qcom/pinctrl-sm6350.c matches "qcom,sm6350-tlmm" — no "lagoon" alias in either. A board DT using upstream’s own compatible strings and node layout would need to be written; the vendor DTB is not reused verbatim. The underlying IP blocks (interconnect, RPMh regulators, tsens thermal, Adreno GPU, ADSP/modem remoteproc, APCS mailbox, SPMI PMIC-arb) are all present in mainline, as found in pass 2.
Wi-Fi (WCN3990)	Upstream driver, one compatible-string difference	Device DTB: compatible = "qca,wcn3990". Mainline ath10k/snoc.c matches "qcom,wcn3990-wifi" — same chip, different vendor-prefix/suffix convention. The wcn3990 references found in pass 2 (core.c/qmi.c/hw.c) appear to be real firmware-loading logic for this exact chip — inferred from the source-code match itself, not confirmed via a live/runtime trace.
Bluetooth (WCN3990)	Upstream driver, binding style differs	Device DTB: compatible = "qcom,btfmslim_slave" — the SLIMbus-attached BT/FM slave binding, an older Qualcomm BSP pattern. Mainline drivers/bluetooth/hci_qca.c matches "qcom,wcn3990-bt" — a different (UART-attached) binding style. Same silicon; whether the vendor kernel routes BT audio over SLIMbus rather than plain UART/HCI is unconfirmed — would need checking artifacts/vendor_a for which path is actually live.
Charging / battery	No mainline driver found for this exact hardware	Device DTB compatibles, found exactly: "qcom,qpnp-smb5" (main charger), "qcom,qpnp-qg" (Qualcomm Gauge fuel gauge), "qcom,smb1396-div2-cp-master" / "-slave" and "qcom,smb1398-pre-regulator" (the dual switched-capacitor charge pumps for fast charging). All four have zero matches anywhere in mainline Linux — checked directly. drivers/power/supply/qcom_smbx.c only matches the older "qcom,pmi8998-charger" / "qcom,pm660-charger" (pre-SMB5 generation); qcom_battmgr.c only matches newer flagship PMIC-glink platforms (SM8550/X1E/SC8280XP-class, not SM6350). This device’s exact charging generation falls in the gap between those two upstream efforts. There is also no charge-pump driver of any kind in mainline (checked: zero hits for div2_cp/smb1390 or similar anywhere in drivers/power/supply/) — no existing driver for the main charger, the fuel gauge, or the charge pumps.
Pen digitizer (Wacom W9021 EMR, I2C)	Confirmed — this project’s own disassembly matches mainline source	drivers/input/touchscreen/wacom_i2c.c uses COMMAND register 0x0004 and DATA register 0x0005, with report type REPORT_FEATURE = 0x30 ORed into the opcode byte. This project’s own, independent disassembly of artifacts/vendor_a/bin/wacom_flash (carried out without reference to the mainline driver) recovered the exact same on-wire convention from the vendor’s own flashing tool: wacom_i2c_set_feature() addresses regA=4/regB=5 and ORs the opcode with 0x30 — a byte-exact match between mainline’s driver and this device’s actual silicon. Remaining difference: device DTB compatible is "onyx,wacom_i2c", and the mainline driver only declares an i2c_device_id ("WAC_I2C_EMR", no of_device_id table) — so it won’t auto-bind via devicetree as-is; needs either a DT compatible change or a one-entry of_device_id patch upstream/downstream.
Capacitive touch (Parade)	Resolved statically — no live read needed	Device DTB: compatible = "parade,pt_i2c_adapter", with a parade,core { parade,name = "pt_core"; parade,hid_desc_register = <0x01>; ... } sub-node. This is Parade’s current driver generation (“pt_core”), not the older Cypress-lineage cyttsp5/"cypress,tt21000" driver that matches on filename — there are zero mainline matches for pt_i2c_adapter or pt_core anywhere. Two further static finds settle the picture without needing a live device read: The kernel config confirms this out-of-tree driver’s real identity: CONFIG_TOUCHSCREEN_PARADE=y plus a full Kconfig submenu (_I2C, _MT_B — standard Linux MT-B input protocol, _DEVICE_ACCESS, _LOADER, _BINARY_FW_UPGRADE, and an Onyx-specific _ONYX_FW_UPDATE) — this is Parade’s own structured driver package (“TOUCHSCREEN_PARADE”), shipped out-of-tree to OEM customers, not a mainline submission. The compiled, currently-running driver is already in this dump, built directly into artifacts/kernel (CONFIG_TOUCHSCREEN_PARADE=y, not =m — no separate .ko exists anywhere in vendor_dlkm/system_a). It was disassembled directly, the same way wacom_flash and the FPGA/EPD internals were earlier in this project — see the next point. (Also confirmed: this kernel compiles in seven Onyx touch drivers — Wacom, Parade, cyttsp5, cyttsp6, FTS, Elan, iStaric — the same “whichever chip answers wins” pattern already documented for the fingerprint sensors, Misc sensors (fingerprint, hall, keyboard cover); Parade/pt_core is the one actually wired up in this unit’s live devicetree fragment.) The runtime protocol was disassembled directly from the driver binary (artifacts/re_static/item_touch_pt_core_recheck.txt): pt_probe (0x9f3a78) is a real, complete driver-init function (5 spinlocks, ~8 linked lists, per-instance naming); the input-report path, pt_parse_input (~0x9eebc0), does a plain, register-less, 2-byte length-prefixed I²C read — read 2 bytes for the pending report length, then read that many more bytes — structurally the same algorithm mainline’s generic drivers/hid/i2c-hid/i2c-hid-core.c uses, and different from the Wacom driver’s explicit command/data-register addressing on the same I²C bus (Capacitive touch (Parade pt_core)). This is code-level support for the HID-over-I2C hypothesis below the DT-property level it was originally raised at. A real firmware blob exists: artifacts/vendor_a/firmware/tp_fw/PT_PIP2_NOTEX_SHENGDIRUI2_5DMM_FW.bin (82,033 B). Its filename gives the wire protocol name — PIP2 (Parade’s 2nd-generation Interface Protocol) — independent confirmation of the pt_core finding. The payload itself was checked and is genuinely encrypted, not just obfuscated: Shannon entropy is ~7.99 bits/byte (near the theoretical maximum) uniformly from byte 0 with no distinguishable low-entropy header, zero repeated 16-byte blocks across 5,127 blocks (rules out ECB-mode or a simple repeating-XOR scheme, the kind of weak obfuscation this project did crack for the OTA AES key in Userspace boot — init, SELinux, A/B updates), and a flat all-256-values byte histogram. No key exists anywhere in this dump (unlike the OTA case) — this is not recoverable statically. Per the Kconfig options above, this blob is inferred to be firmware-update payload for reflashing the touch IC’s own on-chip flash, not something a runtime Linux driver needs to load — i.e. the IC carries this firmware from the factory and the host-side PIP2 command driver talks to it directly. This reading is inferred from the Kconfig option names, not confirmed by a runtime trace.
E-ink display pipeline	No mainline driver	No mainline driver drives a Lattice ECP5 FPGA TCON + software EPD controller of any kind; this is entirely an Onyx-custom stack (the generic e-paper fbdev drivers that do exist upstream — broadsheetfb.c, metronomefb.c, hecubafb.c — target different, older e-reader-era EPD controllers and don’t match this hardware). This project reverse-engineered the pipeline: the FPGA bitstream/command-stream format (E-ink driver internals (register-level, from the kernel)), the /dev/ebc ioctl ABI (The Onyx/Boox platform layer), the waveform (.wbf) format, and the MXO source-driver firmware-selection logic.
Speaker / audio codec chain	Partially upstream	Confirmed upstream: sound/soc/codecs/wcd938x.c / wcd937x.c (headset codec + MBHC) and wsa881x.c / wsa883x.c (the Class-D speaker amp). Not found: a mainline equivalent of the on-SoC “bolero” LPASS codec macro block itself (Vendor drivers and HALs) — only a DMA-side file (lpass-cdc-dma.c) turned up.

14.3. Live confirmation attempted

One adb command was tried against the real device (2026-09-19):

• adb shell cat /proc/bus/input/devices → Permission denied. The touch question was independently resolved statically (kernel config + the PT_PIP2_... firmware filename, see above), without needing this read.

userdata (gigabytes of personal account/app/photo data) is not included in this dump and was not needed: the touch-chip question that would have required it was fully answered from files already in vendor_a instead. This documentation’s methodology treats static artifacts already in the dump as sufficient before any read that would touch personal data.

14.4. What this page still doesn’t cover

Fingerprint sensors (fortsense/chipsailing/microarray, proprietary match-in-sensor SPI modules, Misc sensors (fingerprint, hall, keyboard cover)) and small Onyx-specific misc devices (hall-sensor cover switch, keyboard-ultra2): no mainline match found for fingerprint; the misc devices have no existing driver either. The IMU (LSM6DST) has no direct compatible string in this device’s board DTB at all — consistent with sensors being ADSP/SEE-mediated rather than a direct AP-kernel I2C device (ADSP and CDSP firmware), meaning st_lsm6dsx (a direct-attach AP-side I2C driver) may not be the right architecture to target; this is unresolved. Also unchecked: USB Type-C/PD stack maturity for this exact PMIC combo, and whether the modem/DSP subsystem (present but dormant, ADSP and CDSP firmware) needs porting for a tablet-only use case.

Source:

pass 1 — file/directory presence via raw.githubusercontent.com/torvalds/linux and the GitHub contents API, 2026-09-19. Pass 2 — full-content grep over git clone --depth 1 https://github.com/torvalds/linux /tmp/linux, same day. Pass 3 — compatible-string diff between artifacts/boot_a/board.dts / artifacts/dtbo_a/overlay_0.dts and the matched drivers’ of_device_id/i2c_device_id tables in the same clone, same day.

Cross-refs:

Open questions and limits of analysis, E-ink driver internals (register-level, from the kernel), Wacom EMR pen digitizer driver, Capacitive touch (Parade pt_core), Misc sensors (fingerprint, hall, keyboard cover), Partition map and checksums, Vendor drivers and HALs, ADSP and CDSP firmware.