Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux