On Monday 05 May 2014 09:06:14 Alexander Holler wrote: > > A bit late (I don't follow the ML (or what happens in the ARM world) > closely, but as I've recently read that ARM64 will go UEFI and ACPI, I > wonder what was the reasoning behind that decision. > > Does anyone really assume we will become high quality UEFI and ACPI > blobs from vendors? And such with reasonable support/update periods? > > For me that sounds like someone asked dreamers and was unable to adjust > those answers in regard to reality. Where did you read that? It's simply not true and we should make sure people stop spreading dangerous misinformation. Regarding UEFI, I don't expect that to change much for Linux, since it has very little visibility at runtime. UEFI makes sense for some systems, and we can support that easily. The license is a bit problematic, since it allows shipping a system without bootloader sources, but other boot loaders allow that as well, and a lot of companies ship pirated u-boot without sources, too. ACPI is a lot harder to support, as it conflicts with the normal DT probing method, and will be visible to a lot of drivers. I expect that we will see systems shipping with ACPI at some point, but so far, nobody has made a serious submission for supporting that, so it's likely a few years out, and it will only be a small subset of the shipping systems: basically anything that tries to look like an x86 PC server rather than an embedded system. There is ongoing work from Linaro to provide a base enablement of ACPI on ARM64. Those patches are looking harmless enough, but the current plan is to not merge them until there is an actual user who is submitting their platform specific code based on that, and not before we have clear rules about what systems should or should not be using ACPI. For all embedded systems, DT remains the way to pass data about nondiscoverable devices on arm64, and I expect that to include "server" machines based on embedded SoCs. Arnd -- 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
