==================================================== 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 (:doc:`/open-questions`). 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. Method ====== Four checks at increasing depth: #. **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. #. **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. #. **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." #. **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``. Per-subsystem status ===================== .. list-table:: :header-rows: 1 :widths: 18 15 67 * - 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, :doc:`/sensors/misc`; 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 (:doc:`/sensors/touchscreen`). 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 :doc:`/userspace/platform-boot`), 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 (:doc:`/display/tcon`), the ``/dev/ebc`` ioctl ABI (:doc:`/userspace/onyx-platform`), 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 (:doc:`/userspace/drivers-hals`) — only a DMA-side file (``lpass-cdc-dma.c``) turned up. 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. What this page still doesn't cover ===================================== Fingerprint sensors (fortsense/chipsailing/microarray, proprietary match-in-sensor SPI modules, :doc:`/sensors/misc`) 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 (:doc:`/audio/dsp-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, :doc:`/audio/dsp-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: :doc:`/open-questions`, :doc:`/display/tcon`, :doc:`/display/wacom-pen`, :doc:`/sensors/touchscreen`, :doc:`/sensors/misc`, :doc:`/partition-map`, :doc:`/userspace/drivers-hals`, :doc:`/audio/dsp-firmware`.