On Thu, Aug 22, 2013 at 02:02:29AM +0200, Rafael J. Wysocki wrote: > And now the practice appears to be that vendors actually ship some ACPI > tables with their systems, but those ACPI tables do not contain information > needed to enumerate all devices. On the other hand, it is known what the > DT bindings for the missing part should be. How can we address this? On ARM? I know that this is true on x86, but that's because x86 vendors have never intended i2c hardware monitoring devices be driven by a general purpoes OS - they're there for the benefit of the firmware, not anything above that. > Next, say we have a driver written with DT bindings in mind and there's > an ACPI-based system with identical hardware, although wired up slightly > differently. Say that all of the information needed by that driver is > there in the ACPI tables (Q: How the vendor is supposed to know what > information the driver expects?). Who is supposed to take care of updating > the driver to be able to use ACPI in addition to DTs? Ideally we have a consistent in-kernel representation of this information and drivers don't need to care about whether it came from DT or ACPI, but like I said, that's going to be tricky. > I don't honestly think that the "ask vendors to ship their systems with correct > ACPI tables" approach will take us anywhere. It's worked well enough on x86. If hardware vendors don't actually test that their hardware is able to boot the OS it's intended to run then there's very little we can do about that - and the worst case outcome is that people just ignore the shipped ACPI and use FDT. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
