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

[Catalin Marinas]

On Thu, Aug 28, 2014 at 07:50:36AM +0100, Alexander Holler wrote:
> Am 27.08.2014 18:37, schrieb Stephen Warren:
> > Of course, there are probably cases where we could/should add some more
> > phandles/... and likewise cases where we shouldn't. That's why detailed
> > research is needed.
> 
> Just because I'm curious, I wonder how this research does or shoud look 
> like.
> 
> Defered probes did come to light with 3.4, that was more than 2 years 
> ago. Ok, most people (like me) just noticed it during the last months 
> when they switched to DT and have run into a problem (the deferred probe 
> mechanism is an error-message killer), but some must have seen it 
> already 2 years ago.
> 
> 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).

-- 
Catalin