@mjg59 Counterpoint: I believe that has less to do with ACPI and more to do with the _massive_ amount of work Linux has done to add bug fixes or replacement code for most of those broken ACPI ABI interfaces, which is possible because the chipsets are few and well documented. Where as in Arm or RISC-V it's all under multiple levels of NDA because it's IP blocks in a SoC. Power management is hard, ACPI making a ABI targeting Windows doesn't help.

@alwayscurious @mjg59 There is also the problem that a lot of these vendors _do want upstream support_ but the license agreements with the IP vendors prevent that, and they don't have the wallets or time to push back on the standard license/NDA to open source the driver (which is almost always completely forbidden)

@edolnx @mjg59 Why do the IP vendors insist on keeping things proprietary? Have any vendors decided to pay a third party to write a clean-room reverse engineered driver?

@alwayscurious They keep things proprietary to protect their business model and/or infosec guarantees. Most vendors don't pay for a clean-room reverse engineering effort, that's almost always OSS developers. The ones who are willing to pay will just spend the cash on legal to negotiate terms with the IP vendor to upstream OSS drivers, but that is _rare_ or through a consortium (like Linaro for Arm or RISCstar for RISC-V)

@edolnx How does keeping the interface docs proprietary help them? That seems like security theater to me, as the success of reverse engineering has shown.

@alwayscurious you are correct - it is security theater. It's not about the products, it's about protecting the value of the IP. A known broken IP block is worthless, a IP block that is bound by NDA still has value because you can't tell anyone it is broken. This is also why you can't tell what IP blocks are used, companies don't want end users to know what blocks are in use because end-users are not covered by the NDA. It's all about protecting the business model.