Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757507AbbEVO6X (ORCPT ); Fri, 22 May 2015 10:58:23 -0400 Received: from mga01.intel.com ([192.55.52.88]:59815 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757231AbbEVO6V (ORCPT ); Fri, 22 May 2015 10:58:21 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,475,1427785200"; d="scan'208";a="497077168" From: "Moore, Robert" To: "Williams, Dan J" , Linda Knippers CC: Toshi Kani , Jens Axboe , "linux-nvdimm@lists.01.org" , Neil Brown , Greg KH , "Wysocki, Rafael J" , "linux-kernel@vger.kernel.org" , Linux ACPI , Ingo Molnar , "Zheng, Lv" , Christoph Hellwig Subject: RE: [PATCH v3 02/21] libnd, nfit: initial libnd infrastructure and NFIT support Thread-Topic: [PATCH v3 02/21] libnd, nfit: initial libnd infrastructure and NFIT support Thread-Index: AQHQkz/NaYdQdWzf/kKv4GhSO9h+Rp2G6l4AgAAh9QCAABi4AP//kPDwgAB5OoCAABIugIAACoIAgAAEMQCAABDwgIAACcEAgACsp+A= Date: Fri, 22 May 2015 14:58:18 +0000 Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E37D2EED26@ORSMSX112.amr.corp.intel.com> References: <20150520205536.32249.89779.stgit@dwillia2-desk3.amr.corp.intel.com> <20150520205621.32249.39424.stgit@dwillia2-desk3.amr.corp.intel.com> <1432216514.26714.4.camel@misato.fc.hp.com> <1432229114.28126.25.camel@misato.fc.hp.com> <94F2FBAB4432B54E8AACC7DFDE6C92E37D2EE7C0@ORSMSX112.amr.corp.intel.com> <1432231297.28704.8.camel@misato.fc.hp.com> <1432237458.29840.17.camel@misato.fc.hp.com> <1432238358.29840.25.camel@misato.fc.hp.com> <555E474B.2060306@hp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id t4MEwToC028269 Content-Length: 5917 Lines: 161 It looks to me that you are correct and I screwed up when I made those strings. The odd thing is that we had discussed this whole issue internally for a few days -- then I went ahead and messed up the strings. I think my brain was going around in circles. Anyway, here is the latest info, please have a look: Below is the GUID for volatile memory region directly from the ACPI spec: { 0x7305944F, 0xFDDA, 0x44E3, 0xB1, 0x6C, 0x3F, 0x22, 0xD2, 0x52, 0xE5, 0xD0 } Here is an example of ToUUID using a corrected version of the GUID string. Note that the ordering of the string is identical to the version in the ACPI spec: 11: Name (UUID, ToUUID ("7305944F-FDDA-44E3-B16C-3F22D252E5D0")) Here is the AML output of the ToUUID macro. Note that the first three fields are reversed, the rest of the string is left as-is (as per the ToUUID definition): 00000024: 08 55 55 49 44 ......... ".UUID" 00000029: 11 13 0A 10 4F 94 05 73 "....O..s" 00000031: DA FD E3 44 B1 6C 3F 22 "...D.l?"" 00000039: D2 52 E5 D0 ............ ".R.." This is the important part: 4F 94 05 73 "....O..s" 00000031: DA FD E3 44 B1 6C 3F 22 "...D.l?"" 00000039: D2 52 E5 D0 I believe that this is correct. Thanks for your help, Bob > -----Original Message----- > From: Dan Williams [mailto:dan.j.williams@intel.com] > Sent: Thursday, May 21, 2015 2:35 PM > To: Linda Knippers > Cc: Toshi Kani; Jens Axboe; linux-nvdimm@lists.01.org; Neil Brown; Greg > KH; Wysocki, Rafael J; Moore, Robert; linux-kernel@vger.kernel.org; Linux > ACPI; Ingo Molnar; Zheng, Lv; Christoph Hellwig > Subject: Re: [PATCH v3 02/21] libnd, nfit: initial libnd infrastructure > and NFIT support > > On Thu, May 21, 2015 at 1:59 PM, Linda Knippers > wrote: > > On 05/21/2015 03:59 PM, Toshi Kani wrote: > >> 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 > 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" > > > > I've lost track of the right answer but should we be discussing it in > > the context of this patch too? > > > > http://www.spinics.net/lists/linux-acpi/msg57825.html > > [PATCH 18/19] ACPICA: ACPI 6.0: Add support for NFIT table. > > > > Dan's version of the file has lots of other UUIDs too, beyond NFIT. > > Yeah, it's not clear whether those other GUIDs are actually GUIDs or these > byte-swapped "EFI GUID"s. At least for NFIT it seems that the intent was > EFI GUID ordering due to the note about needing to match the "Disk Type > GUID" format from the EFI spec. > > I circle back with the ACPICA folks. ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?