The upstreamed Qualcomm drivers in the Linux kernel require a device tree from the vendor which doesn't exist yet for this machine, I believe the Linux community has something cobbled together for the ThinkPad x13s, or got something from Lenovo.
> Oh, it's because of "APCI" mode working with openbsd apparently...
Indeed, OpenBSD attempts to support these machines to some extent in ACPI mode, but from what I read the ACPI tables are in bad shape/incomplete. "Good enough for Windows, ship it.".
> but from what I read the ACPI tables are in bad shape/incomplete. "Good enough for Windows, ship it.".
It is a bit more nuanced than this. Qualcomm ships a giant custom (mandatory, most the platform will not even work without it!) driver stack on Windows and uses ACPI definitions more than most x86 platform vendors, to the extent that it even exposed a bug in the Windows ACPI implementation when an ACPI method return buffer would exceed 64 kB so since this generation of SoC a lot of the Windows drivers instead bundle their own 'subset' of certain ACPI buffers and the main DSDT is empty as a result.
Linux on ARM still doesn't really use ACPI except where forces more influential than Qualcomm managed (e.g. SBSA?) so even downstream Linux kernels for Qualcomm still use DT.
Appreciate the additional context. It does seem like though a lot of magic is contained in the Qualcomm Windows drivers, with large parts of the ACPI tables being stubs or broken (requiring hardcoded driver quirks/workarounds).
> Oh, it's because of "APCI" mode working with openbsd apparently...
Indeed, OpenBSD attempts to support these machines to some extent in ACPI mode, but from what I read the ACPI tables are in bad shape/incomplete. "Good enough for Windows, ship it.".