On Wed, Oct 12, 2016 at 2:32 PM, Mark Brown <broonie@xxxxxxxxxx> wrote: > 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 <broonie@xxxxxxxxxx> 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? "Forward" in what way? To convince the Windows people to change their ecosystem? No. >> 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. That is becoming more and more problematic, though, and generally leads to inflated DMI tables in drivers which is not perfect to put it lightly. > 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. That would mean adding static data tables to drivers based on device IDs somehow, but that pretty much would be what happened in the ARM camp before DT, wouldn't it? Thanks, Rafael -- 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
