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 -- 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
