On Tue, Aug 20, 2013 at 01:51:03PM -0700, Darren Hart wrote: > It seems to me that the only way to end up in a situation where the data > is reused by other OSes, is to go through a standards body. What about > attempting to standardize the _DSM method? I suppose the challenge then > is how do we standardize arbitrary data (which, of course, is an > oxymoron)... Right. We could certainly spec the DT bindings that currently exist, but the obvious pushback is that large chunks of it *are* already in ACPI - a _PS0 method (which is ACPI for "Power up the device") that toggles a GPIO pin, and then provides a different GPIO pin in the DT data, which would we believe? > The interesting thing about this to me is that many of these devices are > added after-the-fact (as add-on boards, for example). With the > MinnowBoard we are looking to provide this configuration data in an > EEPROM. Would it make sense for the device manufacturer (rather than the > base-board manufacturer) to define the key-value pairs for their > hardware? Yes, hardware information that's on add-in boards should probably be provided by the add-in board if it carries a ROM. This is trivial on UEFI systems - you just need a UEFI driver for the board that can construct an appropriate SSDT. It's more of a problem for non-UEFI ACPI systems. > Sadly, I will not be in New Orleans and am unlikely to receive a Kernel > Summit invite, but I am planning be in Edinburgh and would like the > opportunity to participate in this discussion. I'm not planning on being at kernel summit this year, so I think we'll try to arrange something around that time but outside the event. -- 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
