Matthew GarrettEvery single ACPI vs Device Tree argument needs to start with the observation that I can boot a modern Linux kernel on an arbitrary x86 board from 1998 and it will probably suspend and resume correctly, and I can't do that with an arbitrary Arm board from 2026
Carl@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.
Demi Marie Obenour@alwayscurious @mjg59 Absolutely - that support for the x86 ecosystem would have been impossible without the hard work by Intel and AMD (and earlier the various chipset vendors). The problem is Arm/RISC-V based SoC parts have none of this standardized. The power management, NOC, clock management: all unique to nearly every chip. For most T1 customers it's not a priority, and if it is for them then the vendor kernel will do what's needed and they don't care beyond that.
@alwayscurious In most of these cases, they are paying for an "embedded solution" - they have a specific use case and are paying for an application specific solution. So that's what ships as the Board Support Package (BSP) for that customer. The customer builds on top of that, and ship it. This is why a lot of OpenWRT network devices still run a 4.10 kernel - it's "good enough" and upstreaming costs money for no direct increase in sales.