On 06/26/2013 01:31 PM, Leif Lindholm wrote: > On Wed, Jun 26, 2013 at 12:32:30PM -0600, Stephen Warren wrote: >>>> What about ARMv8? Is the intention to have a separate definition for the >>>> UEFI bindings on ARMv8, so that compatibility isn't an issue? What if a >>>> future version of UEFI allows LPAE usage? >>> >>> It is unlikely that will happen on v7 since newer versions of UEFI are >>> expected to remain backwards compatible with the current spec. >> >> The expectation of backwards-compatibility sounds nice, but it seems a >> little dangerous to outright rely on it. >> >> Even if not a regular compatible property, can we define a property that >> indicates the UEFI revision or revision of this DT binding, so that if >> we ever have to change it, there is some way of explicitly indicating >> which exact schema the DT corresponds to, rather than having to >> reverse-engineer it from the set of properties that "just happen" to be >> present in DT? >> >> This is rather like the firmware node discussion that happened recently, >> where we were expecting to represent a firmware (secure mode) interface >> by a DT node, which would have a compatible value, which in turn would >> convey information about which "OS" the secure firmware was running, and >> well as any potential SoC-/OEM-/board-specific interface provided by it. >> >> And who knows, what if UEFI gets replaced someday; presumably we'd want >> some way of explicitly stating "running under UEFI" vs. "running under >> something else"? > > To me, these concerns are all covered by the existence of the > efi-system-table node, and the version number that you can extract > from the table (mandatory in any UEFI implementation) located at that > address. There is no reverse-engineering involved. So, what you're saying is that the existence (or lack thereof) of the efi-system-table property is the indicator whether EFI is present? I guess if we assume that EFI will always evolve at least compatibly enough that the system table will always exist and be formatted identically at least to the extent of allowing the EFI version number to be parsed then that's workable. If that guarantee is broken, then we can always define a different property that points at the new format of the table. This still seems a little implicit to me; having an explicit node with an explicit compatible value is much more in line with what's been discussed for other firmware interfaces. However, I suppose it will work fine. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
