On Wed, Oct 12, 2016 at 01:14:18PM +0200, Rafael J. Wysocki wrote: > On Wed, Oct 12, 2016 at 12:28 PM, Mark Brown wrote: > > We appear to not even be trying to set a better standard for how to do > > things here. > Sorry, who's "we"? Linux. > In one case, alternative OSes can handle devices on them through > drivers that contain code dependent on specific device IDs in their > ACPI tables. Right, this is currently the idiomatic way to handle these things in ACPI unfortunately and it's what Windows (which I'm assuming is the alternative OSs you're referencing here!) does. Are people working on trying to move this forwards? > Linux has drivers for those devices too, but they are > based on the of_* interface and expect information from DT that is not If the drivers have DT code that's not well partitioned in the initialization code that sounds like a general problem :( > available from the ACPI tables (and it is not available, because the > drivers working with the alternative OS simply don't need it, as for > them the device ID is sufficient to convey all of the information on > the given device). What we've been doing up until now to support these systems in Linux is to have platform data in the driver that's matched via DMI information. The Windows systems don't appear to be in the slightest bit interested in using the Linux bindings or updating their firmware to accomodate us so the sensible thing is to work in the same way as they do.