ACPI vs DT at runtime

Grant Likely grant.likely at secretlab.ca
Thu Nov 21 13:26:03 EST 2013


On Mon, 18 Nov 2013 12:33:19 -0500, Jon Masters <jonathan at jonmasters.org> wrote:
> On 11/18/2013 03:45 AM, Arnd Bergmann wrote:
> > On Sunday 17 November 2013, Olof Johansson wrote:
> 
> >> Yep, and together for review is a critical part. I'm not saying that
> >> the ideal solution is a flashed DTB, but it's better than ACPI. A
> >> flashed DTB that's _easy to update_ as part of an OS install would
> >> probably be one of the best solutions we could ask for though.
> > 
> > Right: the assumption on the DT boot interfaces is that board designers
> > make mistakes and are working on moving targets, so we need ways to update
> > the DTB. By contrast, the assumption on ACPI is that server firmware
> > authors know what they are doing and you shouldn't let anyone else mess
> > with the ACPI bits because doing so might damage your hardware. We're
> > in trouble if the second assumption turns out wrong.
> 
> In the server space we *never* ship updated ACPI tables in Red Hat
> products, and we never would ship updated tables as part of the OS.
> Platform data is platform data. It belongs to the vendor shipping the
> system, never to the OS. Yes, there are workarounds for bugs but on the
> whole you do in fact count on server vendors not to screw it up, and if
> they do then it is up to them to ship a BIOS update for their hardware.

Agreed, shipping tables with RHEL is insane. If DT is used on the
servers, then the firmware needs to provide the DT, with the option to
override only when *absolutely* necessary.

g.



More information about the linux-arm-kernel mailing list