SystemIO conflicts are not firmware bugs
codon.org.uk> the internet will tell you that PC firmware developers are incompetent³
> ³ I’m not going to present an opinion on that here, merely say that this provides no supporting evidence for that assertion
If anything, isn't this evidence the vendor should've paid someone to write an ACPI driver for Linux? :-)
No. Unless the hardware had Linux stickers on it.
Why should they? Would they sell more hardware if they did? And why Linux? Shouldn't they write an ACPI driver for Haiku first? Companies do what makes money, period. Activist companies have been almost completely wiped out by this stage of capitalism.
Two questions:
1. How does the kernel detect the conflict?
> you can certainly boot with acpi=off if you want to and no ACPI code will be executed at runtime
2. How does the kernel prevent the firmware from running anything?
ACPI firmware is not code that runs by itself. It is code that the kernel interprets. If the kernel doesn't interpret it, it won't run. SMM firmware runs by itself but also can't interact with ACPI locks anyway.
For (1) - ACPI is how the kernel knows what addresses maps where. And when a driver claims the same address space, it knows there's a conflict