On Thu, Oct 6, 2016 at 6:14 PM, Mark Brown <broonie@xxxxxxxxxx> wrote: > On Thu, Oct 06, 2016 at 06:00:39PM +0200, Rafael J. Wysocki wrote: >> On Thu, Oct 6, 2016 at 5:31 PM, Mark Brown <broonie@xxxxxxxxxx> wrote: >> > On Thu, Oct 06, 2016 at 02:19:22PM +0300, Mika Westerberg wrote: > >> >> I don't need a DT, I need that my existing firmware (in this case BIOS) >> >> can describe camera device(s) and the OS can take advantage of this, >> >> preferably with minimal changes to the drivers. > >> >> Currently there is no way in ACPI specification to do that. > >> > That's not exactly true - the way Windows handles audio devices (which >> > follow a similar pattern) is to register the control interfaces of the >> > individual components of the system using existing bindings and then >> > bind them together with a driver that matches the board level >> > identification. This isn't super awesome but it's definitely a thing >> > you can do. > >> But that would mean writing new Linux code to support hardware that >> already is supported by the Linux kernel. > >> That would be a bit like saying "We have a driver for this, but you >> are not allowed to use it, because your platform is not a DT one". >> That doesn't sound good to me, honestly. > > Well, no - it just means that you need a bit of translation code to glue > things together. There's no need to replace the entire driver. Fair enough, but also depending on what is provided by the ACPI tables and what isn't. In some cases kernel frameworks expect information that - without _DSD properties - is not available in the ACPI tables in any form, but can be provided by DT, so the driver would need to contain some sort of a static table mapping device IDs to the missing information which would not be fantastic. 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
