On Wed, Nov 13, 2013 at 3:00 AM, Leif Lindholm <leif.lindholm@xxxxxxxxxx> wrote: > On Tue, Nov 12, 2013 at 04:42:41PM +0000, Will Deacon wrote: >> > ______________________________________________________________________________ >> > Name | Size | Description >> > ================================================================================ >> > linux,uefi-system-table | 64-bit | Physical address of the UEFI System Table. >> > -------------------------------------------------------------------------------- >> > linux,uefi-mmap | 64-bit | Physical address of the UEFI memory map, >> > | | populated by the UEFI GetMemoryMap() call. >> > -------------------------------------------------------------------------------- >> > linux,uefi-mmap-size | 32-bit | Size in bytes of the UEFI memory map >> > | | pointed to in previous entry. >> > -------------------------------------------------------------------------------- >> > linux,uefi-mmap-desc-size | 32-bit | Size in bytes of each entry in the UEFI >> > | | memory map. >> >> Do we actually need to define these sizes here, or can they be dealt with >> using the usual #address-cells property? Also, I think you should describe >> the binding in a separate document somewhere under Documentation/devicetree, >> then cross-reference it from here. > > This is not a generic ABI, so I don't think it belongs in there (it will > never be in a .dtb, and the only way it can be generated by something > that isn't the stub is by lying). > But I don't really care either way - as long as some general agreement > can be had. There is precedence with inserting the initrd location into the kernel with similar properties. I think the binding does the right thing here. In the interest of bike shedding, I would name the properties "linux,uefi-mmap-start" and "linux,uefi-mmap-size", but otherwise it is fine by me. Should you have a property for the descriptor version as returned by GetMemoryMap()? > >> > -------------------------------------------------------------------------------- >> > linux,uefi-stub-kern-ver | string | Copy of linux_banner from build. >> > -------------------------------------------------------------------------------- >> >> Are you sure you want to refer to kernel symbols here? If somebody renames >> that variable, they're not going to fix this file. > > There is a comment above the definition of linux_banner that says: > /* FIXED STRINGS! Don't touch! */ > > Sounded reliable enough to me :) I think this is just fine. g. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
