On Thu, May 21, 2015 at 11:01 AM, Toshi Kani <toshi.k...@hp.com> wrote:
> On Thu, 2015-05-21 at 17:49 +0000, Moore, Robert wrote:
>> What ACPICA has done here is to define these values consistently with the
>> ToUUID ASL macro:
>>
>>
>> Byte encoding of UUID/GUID strings into ACPI Buffer objects (use ToUUID from
>> ASL):
>>
>> Input UUID/GUID String format : aabbccdd-eeff-gghh-iijj-kkllmmnnoopp
>> Expected output ACPI buffer : dd,cc,bb,aa, ff,ee, hh,gg, ii,jj,
>> kk,ll,mm,nn,oo,pp
>>
>
> I do not see any issue in this conversion, which is consistent with
> ToUUID defined in ACPI spec.
>
> My point is that the string format of GUID is endian-neutral. Wiki
> pages and EFI spec agree on it. EFI 2.5 spec, Table 225 (sorry not
> Table 212, which is v2.4), is also clear about how String and Buffer are
> related with actual values of GUID.
I think the critical point from the UEFI spec is the "It should also
be noted that TimeLow, TimeMid, TimeHighAndVersion fields in the EFI
are encoded as little endian". That would imply the byte encoding
of...
{ 0x92F701F6, 0x13B4, 0x405D, 0x91, 0x0B, 0x29, 0x93, 0x67, 0xE8, 0x23, 0x4C }
...should be:
{ f6,01,f7,92,b4,13,5d,40,91,0b,29,93,67,e8,23,4c }
Which implies the text conversion should be:
"92f701f6-13b4-405d-910b-299367e8234c"
...not
> +#define UUID_CONTROL_REGION
> "f601f792-b413-5d40-910b-299367e8234c"
I think ACPICA has the right order for a standard RFC 4122 id, but it
seems EFI is explicitly clarifying that the encoding is little endian
for the initial fields. I think the EFI definition applies due to
this note in the NFIT section of the ACPI spec: "The Address Range
Type GUID values used in the ACPI NFIT must match the corresponding
values in the Disk Type GUID of the RAM Disk device path that describe
the same RAM Disk Type. Refer to the UEFI specification for details."
In hindsight it would have been nice if the NFIT spec had used an
unambiguous text encoding to define these values.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
