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 <rjw@xxxxxxxxxxxxx> wrote: > > On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote: > >> On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: > >> > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
