Am 28.08.2014 11:23, schrieb Catalin Marinas:
On Thu, Aug 28, 2014 at 07:50:36AM +0100, Alexander Holler wrote:
And I wonder how the ACPI world solves that problem. My guess would be
hardcoded stuff in the firmware-blob (BIOS), just like it happened with
board files, but I've never seen BIOS code and my knowledge about ACPI
is almost zero. ;)
ACPI doesn't even attempt to solve such problems at the OS level. SoCs
aimed at ACPI should have simple hardware configuration (from a Linux
perspective) initialised by firmware (e.g. clocks) and devices living on
a standard bus like PCIe. If a SoC requires specific low-level code to
initialise the hardware in a specific order (other than architected
peripherals like GIC, timers; e.g. MFD devices), we should deem it
unsuitable for ACPI.
ACPI should only be used by vendors who know exactly why they need and
how to implement it properly and not just because the marketing
department told them to (it would also be nice if the Linux kernel
community was informed about such reasons).
Hmm, Jon Masters from Red Hat sounds too like UEFI/ACPI is the way to go.
But maybe he's right and hiding ugly code in proprietary/binary firmware
blobs where no one can see and criticize it is really the way to go.
Personally I think it's a way back to the past ("when everything was
better", at least that is what most human brains do like to suggest) and
just a dream. And I don't believe that the stuff which was and is hidden
away always just works and doesn't need fixes (one can't do themself).
In my humble opinion that's a nice but wrong myth and doesn't take into
consideration that HW (and SW) gets more and more complicated too (and
thus more faulty).
And even the biggest companies already have problems to produce stuff
which just works (they just employ humans too), not to speak from
smaller board vendors. So it's much better to keep the source as visible
as possible to as much people as possible (in the OS) and not to rely on
some binary blob as most BIOSes are.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
