On Fri, Nov 15, 2013 at 09:52:41AM -0800, Olof Johansson wrote: > If we knew exactly what we wanted, it'd be a different story. _We > don't_. We're into year FOUR of the device tree conversion and we're just > now reaching a point where we think we know what a good solution looks > like. The first two years were easy -- they were the trivial devices we're > now talking about on ACPI. After that it got harder. Going through all > of that again with ACPI? No. No way. Microsoft gets to do it and while > they're busy sorting it out, we'll boot with device tree. However, there's a very big danger here. I disagree with the stance you're taking. It seems that under ACPI and DT, we refer to properties by string names. That's good, but do we really want to have different string names for the same property. Or worse still, the same hardware property described in two completely different ways between ACPI and DT? If you think Microsoft will come along, look at what we've done for DT, and implement something in ACPI which is somehow compatible with that, I'd have to ask where you've been for the last 30 years. That's not how Microsoft operates. Microsoft will instead design something different (whether it's intentionally different or not depends on your point of view) but it will be designed how they want and not how we'd like it to be. From their point of view, if it's completely different and very difficult to convert to device tree, that's a win for them because it means they're pushing back on Linux being used in markets they wish to be successful. We have a possibility here to define how we'd like ACPI to look: we have the chance to have ACPI properties using the same naming that we already have for DT. What this means is that _if_ we wanted one day to have first class support for ACPI (which we may wish to for the AML) then we wouldn't have to rewrite all the drivers we've already converted. Yes, we'd have a some churn, but most of that would be along the lines of converting the of_* calls to being firmware_* calls, taking a generic firmware handle. Who knows, we may decide in the future that we want to move everything over to ACPI rather than using DT, and having things as I mention above would make it much easier to convert from DT to ACPI. I believe that we're only going to regret shutting the door on this in the future. It's not like the kernel doesn't already have native support for ACPI. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
