On 14 October 2014 12:59, Leif Lindholm <leif.lindholm@xxxxxxxxxx> wrote:
> On Mon, Oct 13, 2014 at 03:48:33PM +0200, Ard Biesheuvel wrote:
>> Version 3.0 of the DTMF SMBIOS reference spec defines a new entry point
>> type that supports a 64-bit address for the SMBIOS structure table. This
>> is needed by platforms whose system RAM resides above the 4 GB physical
>> address boundary, such as upcoming 64-bit ARM platforms.
>>
>> This is a preliminary RFC implementation, as there is no definition available
>> yet for SMBIOS3_TABLE_GUID, which the (currently still in draft) SMBIOS v3.0
>> spec refers to.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
>> ---
>> goto out;
>> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
>> index 8590099ac148..9035c1b74d58 100644
>> --- a/drivers/firmware/efi/efi.c
>> +++ b/drivers/firmware/efi/efi.c
>> @@ -30,6 +30,7 @@ struct efi __read_mostly efi = {
>> .acpi = EFI_INVALID_TABLE_ADDR,
>> .acpi20 = EFI_INVALID_TABLE_ADDR,
>> .smbios = EFI_INVALID_TABLE_ADDR,
>> + .smbios3 = EFI_INVALID_TABLE_ADDR,
>
> Is there any particular need to add a separate pointer for v3?
> In both cases, the pointer is a physical address stored as an unsigned
> long.
>
Yes, but they point to different header types, and the firmware could
legally provide either type or both (in which case, they may point to
the same SMBIOS structure table, or to distinct ones), and it is up to
DMI to interpret that, not EFI.
At the DMI level, we should be strict IMO and only interpret the new
_SM3_ entry point header if it was supplied using the
SMBIOS3_TABLE_GUID, so even if we use the same table pointer, we would
need to store additional data regarding which GUID was used.
--
Ard.
--
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
