On Wednesday, October 21, 2015 10:55:14 AM Geert Uytterhoeven wrote:

Hi Rafael,

On Wed, Oct 21, 2015 at 1:34 AM, Rafael J. Wysocki [off-list ref] wrote:

quoted

On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote:

quoted

On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki [off-list ref] wrote:

quoted

ACPI uses platform devices too.  In fact, ACPI device objects are enumerated as
platform devices by default now.

Okay, I should have grepped for that:
drivers/base/platform.c:                ACPI_COMPANION_SET(&pdev->dev, NULL);
drivers/base/platform.c:        len = acpi_device_modalias(dev, buf,
PAGE_SIZE -1);
drivers/base/platform.c:        rc = acpi_device_uevent_modalias(dev, env);
drivers/base/platform.c:        /* Then try ACPI style match */
drivers/base/platform.c:        if (acpi_driver_match_device(dev, drv))

These are all cases which have DT version as well, so we're not really
all that different here. There's a few more for DT, but that probably
means you have just not hit the problems we have yet. For example,
what happens if you have an interrupt line in which the controller is
probed after the device connected to the interrupt line? That required
resolving irqs in platform_get_irq rather than using static resources
to support deferred probe.

We don't have this particular problem, because the IRQ controllers are
enumerated in a special way.

What does "in a special way" mean? Can you please be more specific?

Can you have interrupt controllers that depend on clocks, pin controllers,
and PM domains?

Currently, there's no native way to represent those dependencies in ACPI.

Thanks,
Rafael