Needing the kernel to be changed for each device is an Androidism that encourages ewaste and we should fight against it.
Instead Qualcomm should improve their ACPI implementation and improve the kernels handling of it
Instead Qualcomm should improve their ACPI implementation and improve the kernels handling of it
It's an Armish not an Androidism. It's an embedded legacy that really doesn't make sense anymore. But inertia is powerful enough that even Apple is still using device trees, even on their M series SoCs ( https://asahilinux.org/docs/fw/adt/ )
I'm not a kernel developer, but it seems to be one of those things that's great when you're adding support for a particular device on a particular platform, but becomes a giant PITA in the aggregate for the downstream ecosystem. It's a mismatch of incentives and preferences.
Kernels always have to be changed for different hardware, that's nothing new. x86 kernels don't run on ARM machines, full stop. Gameboy Advance kernels don't run on Switch 2. IBM mainframe kernels don't run on AWS EC2.
As part of good engineering practice we like to separate the parts that are volatile with regard to hardware changes from the parts that are nonvolatile. But that's a kernel implementation detail and we shouldn't pretend it means the combined kernel doesn't need to be changed.
We can also embed several volatile components for several different hardware configurations. That's called inefficiency, or bloat.
There were several attempts for hardware to incorporate the volatile component itself and be self-describing. ACPI (in ROM) is one; device-tree-in-ROM is another. Neither turned out to work well, because it turns out you actually want to evolve that code and so kernels contain lists of ROM patches anyway, which isn't much better than just including whatever was in the ROM to begin with.
Isn't there a way to have loadable device drivers that live outside the kernel?
This is definitely a thing in some embedded systems I’ve used. There are some Marvell boards which do this. They all use U-boot though.
However, there is a fatal flaw in the process that makes this a pipe dream in reality. In Linux, these rules only apply to reviewed and merged drivers. And during review any new DT interface will almost certainly be bikeshedded in some way.
So unless your chip vendor has upstreamed ALL their drivers before a device is manufactured, the device's firmware-provided DT will very likely work only against a vendor kernel and requires updating.