undefined | Better HN

0 pointsmy1234y ago0 comments

> Windows-specific mess that has close to zero standard PNP* things

Those are hardware dependent platform devices. Qualcomm didn’t have another option. (Nor do other manufacturers really)

On x86, a virtual PCIe bus abstraction is heavily used, which is not the case for those SoCs.

(And well, if Linux wants to boycott full support of their SoCs, their choice. They just can’t blame Qualcomm anymore at that point.)

Another thing of note is the use of a PEP (power management plug-in) in the OS instead of having power management done in AML. The ACPI spec allows a manufacturer to do this. It isn’t used only by Qualcomm, but is totally unsupported on Linux today.

0 comments

2 comments · 1 top-level

floatboth4y ago· 1 in thread

Manufacturers have the option of producing standards-compliant goddamn hardware! Say for PCIe, even if it's a buggy and quirky implementation but it does support ECAM, you can still expose a PNP0A08 and deal with quirks in firmware (hello Socionext/Marvell/NXP).

> PEP (power management plug-in) in the OS […] ACPI spec allows a manufacturer to do this

Doing management in AML is almost the whole point of ACPI. Microsoft pushing this PEP thing into the ACPI spec is bad. This is the "letter" of ACPI now, unfortunately, but it's very much against the original "spirit" of ACPI :/

my123OP4y ago

> Manufacturers have the option of producing standards-compliant goddamn hardware

For PCIe indeed, but that’s not when the issues are present the most. There’s no standard register interface for integrated GPUs, modems…

> but it's very much against the original "spirit" of ACPI

Yup, it’s what Device Tree does too however, shifting this to the OS.

Another downside is trying to have a good driver-less boot scenario when PEPs are used, for the system to be able to go far enough until drivers can be installed. (N/A to Linux which is hostile to not in-tree drivers, but very much a concern on Windows)

j / k navigate · click thread line to collapse