On Thu, Aug 28, 2014 at 07:50:36AM +0100, Alexander Holler wrote:

Am 27.08.2014 18:37, schrieb Stephen Warren:

quoted

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