Re: [PATCH v3 02/21] libnd, nfit: initial libnd infrastructure and NFIT support

[Toshi Kani <toshi.kani@hp.com>]

On Thu, 2015-05-21 at 13:44 -0600, Toshi Kani wrote:
> On Thu, 2015-05-21 at 12:06 -0700, Dan Williams wrote:
> > On Thu, May 21, 2015 at 11:01 AM, Toshi Kani <toshi.kani@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 }
> 
> The above NFIT GUID as data values means:
> 
> EFI_GUID(0x92F701F6, 0x13B4, 0x405D, 0x91, 0x0B, 0x29, 0x93, 0x67, 0xE8,
> 0x23, 0x4C)
> 
> > Which implies the text conversion should be:
> > 
> > "92f701f6-13b4-405d-910b-299367e8234c"
> 
> Nope.

Oops! Sorry, I misread your email... The above string is correct,
although I do not think you need such conversion. 

> EFI 2.5 spec, Appendix A "GUID and Time Formats" defines that:
> (NOTE, I simplified the table 225 to fit in this email)
> ==
> This specification also defines a standard text representation of the
> GUID. This format is also sometimes called the “registry format”. It
> consists of 36 characters, as follows:
> 
> aabbccdd-eeff-gghh-iijj-kkllmmnnoopp
>  :
> 
> Table 225. Text representation relationships
> String	Offset In Buffer   EFI_GUID
> aa	3                  Data1[24:31]
> bb      2                  Data1[16:23]
> cc      1                  Data1[8:15]
> dd      0                  Data1[0:7]
>  :
> ===
> 
> Therefore:
> 
> aa = Data1[21:31] = 92
> bb = Data1[16:23] = F7
> cc = Data1[8:15]  = 01
> dd = Data1[0:7]   = F6
> 
> > ...not
> > 
> > > +#define UUID_CONTROL_REGION             "f601f792-b413-5d40-910b-299367e8234c"
> 
> Hence, the above string is correct.

Misread again... Right, the above string is NOT correct.

I think we are on the same page that the GUID strings in this patch need
to be changed.

{ 0x92F701F6, 0x13B4, 0x405D, 0x91, 0x0B, 0x29, 0x93, 0x67, 0xE8, 0x23,
0x4C }

should be defined as:

"92f701f6-13b4-405d-910b-299367e8234c"

Thanks,
-Toshi


> ToUUD then stores the given string to Buffer according to "Offset In
> Buffer" in the above table.
> 
> Another example, EFI 2.5 spec defines GPT partition GUID:
> 
> ===
> Table 19. Defined GPT Partition Entry - Partition Type GUIDs
> EFI System Partition C12A7328-F81F-11D2-BA4B-00A0C93EC93B
> ===
> 
> The kernel defines it as:
> #define PARTITION_SYSTEM_GUID \
>     EFI_GUID( 0xC12A7328, 0xF81F, 0x11d2, \
>               0xBA, 0x4B, 0x00, 0xA0, 0xC9, 0x3E, 0xC9, 0x3B)
> 
> Thanks,
> -Toshi
> 
> _______________________________________________
> Linux-nvdimm mailing list
> Linux-nvdimm@lists.01.org
> https://lists.01.org/mailman/listinfo/linux-nvdimm