From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (NAM10-BN7-obe.outbound.protection.outlook.com [40.92.40.55]) by mx.groups.io with SMTP id smtpd.web10.144044.1598045149097666270 for ; Fri, 21 Aug 2020 14:25:49 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@outlook.com header.s=selector1 header.b=qYjcYpGm; spf=pass (domain: outlook.com, ip: 40.92.40.55, mailfrom: michael.kubacki@outlook.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n6B6XFFzaa6uFSwlkL2LS2dKL9KuML2NeQfUGjMbGwByX7c/E++D0Wy6KYPouPudE/r880BbEoravCz5EYDEePC6K3udCmnWgqlADfTKwa+TAHZQB7VJfBryzo3krggkAZDElz4tlaY5YfUGO8S9auKhDEoOnIX+AWjinsv7XEDix//JhQACCtxj6JsHRSkqZo7M5FNEWfhQ/Mxq0T3yqb2amHituGpkpfgeN3huAnhYpJLTRwzMxcyqOa+p6ZNLmC21zmkpN/+vFyVmr38CFPXvhl1m4wL/mpXchktccxstFFccWvqACHhktmoQ/mn2QJmW6w9fYpEJ0D85jCPgtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QUz6bu+s9qLcJRDrkPe8p5d0hEZZwIHcx3ya8n+FOEM=; b=oKubFU+2OE9pda6zY/X3t8CIY07+BMvC9XTbvxvhqclRXCVCA+RNAG7ZC00imW9N/V7qvC+9yZ1bnEnsiwMj19em0h80s1Q0gztz7YpNWXjVSjOOg8ULhrL5ZWeK5I+yuAUANiulc4SkSeezTXiXeBNr3Xljwg6uCKMhcNHhf2XM9fvGd0qi36vIPW3ER48opv9Nwp6IBma8Ac+y+TL5E6SBA8ClLguwnLIVRnpOXyB8lp6O1n9WvMmToqHsQLHF0WxGb7xp9ymntMBXbGDC57ykiwKO2NUfCBIFsgJVKAmJFbSgUDqCONVWM4eoDObjHDvaK5kcf5LWjBhaAEqPsA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QUz6bu+s9qLcJRDrkPe8p5d0hEZZwIHcx3ya8n+FOEM=; b=qYjcYpGmiDl/Q0Dve71/Dm/SPWOmwL502B4Tn/dAawt+GykupM5GsRt2K3OZs7HFnS9TiqK4Dv64wKXsz6SdtO5OYVCUvNjQEfOkvGFXaU3aaajD3ClR1uOL5j1Alcjjen7Ey1aWAhwPk2eZoLgrlViLkKElKxoIknVVL5bGdTbohziijABPP9SMBpZwZ+7ftL977RRBb++kyrcsvSCf1FLCeWb+t1Hj5ILI1IIqx76LwkklyQYgiVWI2lEf6/5MWyc0yN6LEbcxv5uOwEE3aVLQKc9E9j3nUGC5RMeDJpoq1+w2Yz4uDF31/24oLH1BDfUwB6ki3Ony7W2IYp2RIA== Received: from BN7NAM10FT062.eop-nam10.prod.protection.outlook.com (2a01:111:e400:7e8f::51) by BN7NAM10HT018.eop-nam10.prod.protection.outlook.com (2a01:111:e400:7e8f::357) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.24; Fri, 21 Aug 2020 21:25:47 +0000 Received: from MWHPR07MB3440.namprd07.prod.outlook.com (2a01:111:e400:7e8f::4d) by BN7NAM10FT062.mail.protection.outlook.com (2a01:111:e400:7e8f::299) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.24 via Frontend Transport; Fri, 21 Aug 2020 21:25:47 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:0664C86ECB2D34827B3F2B7BA779F17B2D85C27055E42C7266DCF84D83D4992F;UpperCasedChecksum:B112D4A1D18FDFD279E2E712AEC3E11A821A30BFD18C9F1940B62EB921BF088F;SizeAsReceived:9363;Count:49 Received: from MWHPR07MB3440.namprd07.prod.outlook.com ([fe80::eda9:ccc8:2ef:2471]) by MWHPR07MB3440.namprd07.prod.outlook.com ([fe80::eda9:ccc8:2ef:2471%7]) with mapi id 15.20.3305.026; Fri, 21 Aug 2020 21:25:46 +0000 Subject: Re: [edk2-devel] [PATCH v3 0/6] Extend Last Attempt Status Usage To: Sean Brogan , devel@edk2.groups.io, "Kinney, Michael D" CC: "Gao, Liming" , "Jiang, Guomin" , "Xu, Wei6" , "Liu, Zhiguang" References: From: "Michael Kubacki" Message-ID: Date: Fri, 21 Aug 2020 14:25:46 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 In-Reply-To: X-ClientProxiedBy: MW3PR05CA0023.namprd05.prod.outlook.com (2603:10b6:303:2b::28) To MWHPR07MB3440.namprd07.prod.outlook.com (2603:10b6:301:69::28) Return-Path: michael.kubacki@outlook.com X-Microsoft-Original-Message-ID: MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from 255.255.255.255 (255.255.255.255) by MW3PR05CA0023.namprd05.prod.outlook.com (2603:10b6:303:2b::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.10 via Frontend Transport; Fri, 21 Aug 2020 21:25:46 +0000 X-Microsoft-Original-Message-ID: X-TMN: [fZ0PL8JRr5TCfBuXUoOcv1Kgv1+BxPhshP8dKTmbCMNYFqBWXwvDvW8S5WUF/OA/] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 49 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: ca4953e1-7f45-48f5-9665-08d84618c4b7 X-MS-Exchange-SLBlob-MailProps: jGdi06XMWgCQtnU7VklCqMLRUyuCY9MFz/uFj34BoXBpWaAIunDCxlWCbz2PUC8m4kWuVobuF0UxMVrI0eo7mMfdbGjFVlTiTFzMp+RcnKwdas4GXe6d997Bx2hD36f3RvXaTAMOWGqalC6QiJibgh6F24Vc4dU3JP21/IspDBZ1TNqUwhku3vNgl5Y0Omb7Ml981xOi7h3rRXtyBHSpk4VqN7DeqS6L22kte6PFekuBVd6lONCKALzxrH6rZQzRXDjWgnA7es5isQlXNG/m9UMF5fMrubCjOxZ3GpxZfTFif21vzZ90JOFQ9z9iVn01T4uJ07buR57o3QLLPMqHIlQhgCSGlej+0/mQg3aobk4aw3iYVqPVFSVb/Xa6uuNwI1vA2L0WtkMLw5a4jk/3RUjavyutxo7pttwbvP8BKAIXtaod8+tthJlK1omfW6EWRDouZLvJhjsNAtUh0fyje8sX/r7O/wpARbG2II7n1kFFGSQ5vLdJ87NApHXfefyFs/KZjunqm0Wap3yqgUHSTXEqD9LcE1pOnrVUHdiUuJcAopC9YYi5IVgraC1kbPNNN+R7t5xgVhVa+YBJdBahJupPMmFWdxXZ29G3VwViBeCEc7TTKAhnZypOux7ERp/X69UdKPVVJElb65D5nbmgXMEx3ery9gO8+08j8cXIaEIHjRocQ1QJwObLPP2+twfNfTc/lpG2BLDrAinHsr4UTHam6rQ9cBy8rA2DoRAYE7B74DQbNsIB8qOvmnzEy2+fbiLR8gcOlVWIk3ludKGoWo9SG6NeF0Z9OznPHMMLu6/Kzdll0Akods7uGPz7imT730meZDyqW1jXhuGNr++jc3iiKmxzUjOhaN/pxBpoUqoiFOm9pTyeu4CoUo3DUY4r4ipTKLrh0BWetgsZBYBmI2NIbgG4q1FOXxR8DnWyj0BXUCs7mhtogvyy/Wxd4sGr3Tm4IuB5ZmpH2aNBh0QQxMy/kdOQT8hK X-MS-TrafficTypeDiagnostic: BN7NAM10HT018: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: NT0O32JTdxfZQxR3jsC+GdxIiMcYl4edU3hoOAfo2XnNks0/DACI0OsJA6IJI4UWkMBrLyGLrMOheYHUUOJpL7FJ7idmYRCAyLp/wyt5rXATp6mDGHu6hDN+ITGzGoAg/rh0qFDEhSM5ciBRtabk+jjgwL86Leq5xnIh9LK1uePr71dM4UW5MK03RluBMS533KlVjO1k8UHo6wSKcqMCoRNjzNWCUxgrmh/JTypJ54ypZqyRUf92v3mSVqVqHmGr X-MS-Exchange-AntiSpam-MessageData: 3wzcE/Jkl12PBquMBjRRYFsJNufN4WKs+gHqsNHBBIafQmDdo4tUb/KIy3ZZvAZt1t9RRF9LVdNdkDeILPW/7cJE8B9UaiUoI/39Vx8I9IB/0PUEYWBCNLJfKL/vWLgAi0mWTMVR0+ihIXcU9A0doO+BdNiuaoidCNv2WzEQMYx+YXyFQ6JvKEuCEhTkj80dIT2ZD4qFETByx+w7EHosZA== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ca4953e1-7f45-48f5-9665-08d84618c4b7 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Aug 2020 21:25:46.9368 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-AuthSource: BN7NAM10FT062.eop-nam10.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7NAM10HT018 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Sean, Thanks for the feedback. #1 - I will include both suggestions in v4. Thanks, Michael On 8/20/2020 7:37 PM, Sean Brogan wrote: > Michael, >=20 > #1 > I would suggest calling out the sub-range >=20 > 0x10A0 | 0x17FF=C2=A0 -- Free for Library Implementations of FmpDevicePk= g >=20 > I also might suggest splitting FmpDependencyLib and=20 > FmpDependencyCheckLib ranges just to show a consistent pattern of how=20 > each library instance within FmpDevicePkg gets a defined range. >=20 >=20 > #2 > Given that edk2 does not have any real FmpDeviceLibs (only instance is= =20 > FmpDevicePkg\Library\FmpDeviceLibNull\FmpDeviceLibNull.inf).=C2=A0 Now i= s the=20 > best time to make a breaking change. It is very common for downstream=20 > code repositories to integrate edk2 and be forced to make changes=20 > associated with the new integration.=C2=A0 To me this is preferred.=C2= =A0 A build=20 > break is easy to resolve. When functionality changes or new features are= = =20 > added but don't cause a break this is more difficult to integrate=20 > correctly.=C2=A0 Not only that, it leads to nearly everyone ignoring the= = =20 > change.=C2=A0 There is no need for this change to be a multi-year integr= ation=20 > or cause extra development of shims and translation functions.=C2=A0 The= API=20 > change is pretty easy.=C2=A0 The implementation can choose to to avoid t= he=20 > new ranges and just set the value to 1 (FMP unknown error).=C2=A0 This w= ould=20 > match the behavior of today.=C2=A0 Obviously i believe it would better t= o=20 > take the extra time to create unique ranges for each of your libs.=C2=A0= Also=20 > note that if anyone is doing third party binary integration this is not= =20 > a breaking change.=C2=A0 This only breaks for those doing a src build. >=20 > Thanks > Sean >=20 >=20 >=20 >=20 >=20 >=20 > On 8/20/2020 6:25 PM, Michael Kubacki wrote: >> Hi Mike, >> >> 1) Yes, we can certainly leave more of the unsuccessful vendor range=20 >> available for future expansion. I believe we can also reduce the FMP=20 >> reserved range. How about a length of 0x800 for both? >> >> The ranges would then be defined as follows: >> >> START=C2=A0=C2=A0=C2=A0=C2=A0 | END=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= | Usage >> ------------------------------------------------------------------| >> 0x1000=C2=A0=C2=A0=C2=A0 | 0x17FF=C2=A0=C2=A0=C2=A0 | FmpDevicePkg=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 | >> =C2=A0=C2=A0=C2=A0 0x1000 |=C2=A0=C2=A0=C2=A0 0x107F | FmpDxe driver=C2= = =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 | >> =C2=A0=C2=A0=C2=A0 0x1080 |=C2=A0=C2=A0=C2=A0 0x109F | FMP dependencies= (e.g. FmpDependencyLib)=C2=A0 | >> 0x1800=C2=A0=C2=A0=C2=A0 | 0x1FFF=C2=A0=C2=A0=C2=A0 | FmpDeviceLib inst= ances implementation=C2=A0=C2=A0=C2=A0=C2=A0 | >> 0x2000=C2=A0=C2=A0=C2=A0 | 0x3FFF=C2=A0=C2=A0=C2=A0 | Unused. Available= for future expansion.=C2=A0=C2=A0 | >> >> Also, I don't see a problem with removing the length defines and=20 >> directly specifying min/max defines for each range. >> >> 2.) I understand the compatibility concern but as you noted it is=20 >> cleaner to maintain a single interface. I believe making the=20 >> transition to the new API will only become more difficult in the=20 >> future as it may go unnoticed resulting in implementations that don't= =20 >> implement support for this capability leading to an increasing amount= =20 >> of future effort to do work that could be done now. Perhaps we could=20 >> get thoughts from others as well? >> >> 3.) I will update these to return back an expected value. >> >> Thanks, >> Michael >> >> On 8/19/2020 7:57 PM, Kinney, Michael D wrote: >>> Hi Michael, >>> >>> A couple a couple general questions: >>> >>> 1) I see the entire range from 0x2000-0x3FFF is reserved for=20 >>> FmpDeviceLib.=C2=A0 If we >>> =C2=A0=C2=A0=C2=A0 every add more device/platform specific libs for FM= P, there are=20 >>> no ranges available. >>> =C2=A0=C2=A0=C2=A0 Should we limit the FmpDeviceLib to a smaller range= to support=20 >>> future expansion? >>> >>> =C2=A0=C2=A0=C2=A0 Also, the style of LastAttemptStatus.h with extra d= efines for the=20 >>> length of >>> =C2=A0=C2=A0=C2=A0 each range is hard to read, and I do not think ther= e are any=20 >>> consumers of the >>> =C2=A0=C2=A0=C2=A0 length defines from this public include file.=C2=A0= Since there are=20 >>> really only 3 >>> =C2=A0=C2=A0=C2=A0 defined ranges, couldn't this be simplified to min/= max defines=20 >>> for each range >>> =C2=A0=C2=A0=C2=A0 for a total of 6 #defines.=C2=A0 I do not expect ra= nges (once defined)=20 >>> to change in >>> =C2=A0=C2=A0=C2=A0 length, and the most that might happen in the futur= e is adding=20 >>> new ranges for >>> =C2=A0=C2=A0=C2=A0 new lib classes in the unused ranges. >>> >>> 2) This series makes non-backwards compatible changes to some of the= =20 >>> lib classes. >>> =C2=A0=C2=A0=C2=A0 I agree this is the cleanest way to add support for= the vendor=20 >>> specific >>> =C2=A0=C2=A0=C2=A0 last attempt status.=C2=A0 It does mean that existi= ng implementations=20 >>> will have >>> =C2=A0=C2=A0=C2=A0 to update their lib implementations to be compatibl= e with this=20 >>> new version. >>> =C2=A0=C2=A0=C2=A0 I would be slightly cleaner to introduce new APIs w= ith support=20 >>> for the >>> =C2=A0=C2=A0=C2=A0 vendor specific last attempt status codes.=C2=A0 Th= en update all libs=20 >>> to produce >>> =C2=A0=C2=A0=C2=A0 both the existing APIs and the new APIs (The old AP= Is can call=20 >>> the new APIs). >>> =C2=A0=C2=A0=C2=A0 Then update FmpDxe to use the new APIs.=C2=A0 This = would be 3 patch=20 >>> series. >>> =C2=A0=C2=A0=C2=A0 If FmpDxe never calls the old APIs, then we could (= at a future date) >>> =C2=A0=C2=A0=C2=A0 delete the old APIs from the lib class and the lib= =20 >>> implementations could >>> =C2=A0=C2=A0=C2=A0 remove the old API that calls the new API. >>> >>> 3) The following APIs in the Null implementations have OUT params. >>> =C2=A0=C2=A0=C2=A0 Should these OUT params be set to an expected value= ? >>> >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CheckFmpDependency() >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FmpDeviceGetImage() >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FmpDeviceSetImage() >>> >>> Thanks, >>> >>> Mike >>> >>>> -----Original Message----- >>>> From: michael.kubacki@outlook.com >>>> Sent: Tuesday, August 18, 2020 2:16 PM >>>> To: devel@edk2.groups.io >>>> Cc: Gao, Liming ; Kinney, Michael D=20 >>>> ; Jiang, Guomin=20 >>>> ; Xu, >>>> Wei6 ; Liu, Zhiguang >>>> Subject: [PATCH v3 0/6] Extend Last Attempt Status Usage >>>> >>>> From: Michael Kubacki >>>> >>>> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3D2802 >>>> >>>> This patch series adds more granularity to Last Attempt Status >>>> codes reported during FMP check image and set image operations >>>> that greatly improve precision of the status codes. >>>> >>>> The unsuccessful vendor range (0x1000 - 0x4000) was introduced >>>> in UEFI Specification 2.8. At a high-level, two subranges are >>>> defined within that range in this patch series: >>>> =C2=A0=C2=A0 1. The FMP Reserved range - reserved for components impl= emented >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in FmpDevicePkg. >>>> =C2=A0=C2=A0 2. The FMP Device Library Reserved range - reserved for >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FmpDeviceLib instance-specific usage. >>>> >>>> The ranges are described in a public header file LastAttemptStatus.h >>>> while the specific codes used within FmpDevicePkg implementation >>>> are defined in a private header file FmpLastAttemptStatus.h. >>>> >>>> FmpDeviceLib instances should use the range definition from the >>>> public header file to define Last Attempt Status codes local to >>>> their library instance. >>>> >>>> Of note, there's multiple approaches to assigning private status >>>> codes in the FMP Reserved range. For example, individual components >>>> could define their last attempt status codes locally with the >>>> range allocated to the component defined in a package-wide private >>>> header file. However, one goal of the granularity being introduced >>>> is to provide straightforward traceability to an error source. >>>> >>>> For that reason, it was chosen to define a constant set of codes at >>>> the package level in FmpLastAttemptStatus.h. For example, if a new >>>> FmpDependencyLib instance is added, it would not be able to reassign >>>> status code values in the pre-existing FMP Dependency range; it >>>> would reuse codes for the same error source and be able to add new >>>> codes onto the range for its usage. I wanted to highlight this for >>>> any feedback. >>>> >>>> V3 changes: >>>> =C2=A0=C2=A0 1. Enhanced range definitions in LastAttemptStatus.h wit= h more >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 completeness providing length, min, an= d max values. >>>> =C2=A0=C2=A0 2. Moved the actual Last Attempt Status code assignments= to a >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 private header file PrivateInclude/Fmp= LastAttemptStatus.h. >>>> =C2=A0=C2=A0 3. Changed the value of >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LAST_ATTEMPT_STATUS_ERROR_UNSUCCESSFUL= _VENDOR_RANGE_MAX >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to 0x3FFF instead of 0x4000 even thoug= h 0x4000 is defined in >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the UEFI specification. The length is = 0x4000 but the max >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 allowed value should be 0x3FFF. This c= hange was made now to >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 prevent implementation compatibility i= ssues in the future. >>>> =C2=A0=C2=A0 4. Included "DEVICE" in the following macro name to clea= rly >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 associate it with the FmpDeviceLib lib= rary class: >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LAST_ATTEMPT_STATUS_DEVICE_LIBRARY_ERR= OR_xxx >>>> =C2=A0=C2=A0 5. Included a map to help the reader better visualize th= e range >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 definitions in LastAttemptStatus.h. >>>> =C2=A0=C2=A0 6. Included additional documentation describing the enum= in >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FmpLastAttemptStatus.h. An explicit st= atement stating that new >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 codes should be added onto the end of = ranges to preserve the >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 values was added. >>>> =C2=A0=C2=A0 7. Simplified error handling logic in FmpDxe for FmpDevi= ceLib >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 calls that return Last Attempt Status. >>>> =C2=A0=C2=A0 8. V2 had a single memory allocation failure code used f= or >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 different memory allocations in CheckF= mpDependency () in >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FmpDependencyLib. Each potential alloc= ation failure was >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 assigned a unique code. >>>> >>>> V2 changes: >>>> =C2=A0=C2=A0 1. Consolidate all previous incremental updates to >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LastAttemptStatus.h into one patch (pa= tch 2) >>>> =C2=A0=C2=A0 2. Move LastAttemptStatus.h from Include to PrivateInclu= de >>>> =C2=A0=C2=A0 3. Correct patch 1 subject from "FmpDevicePkg" to "MdePk= g" >>>> >>>> Cc: Liming Gao >>>> Cc: Michael D Kinney >>>> Cc: Guomin Jiang >>>> Cc: Wei6 Xu >>>> Cc: Zhiguang Liu >>>> Signed-off-by: Michael Kubacki >>>> >>>> Michael Kubacki (6): >>>> =C2=A0=C2=A0 MdePkg/SystemResourceTable.h: Add vendor range values >>>> =C2=A0=C2=A0 FmpDevicePkg: Add Last Attempt Status header files >>>> =C2=A0=C2=A0 FmpDevicePkg/FmpDxe: Add check image path Last Attempt S= tatus >>>> =C2=A0=C2=A0=C2=A0=C2=A0 capability >>>> =C2=A0=C2=A0 FmpDevicePkg/FmpDxe: Improve set image path Last Attempt= Status >>>> =C2=A0=C2=A0=C2=A0=C2=A0 granularity >>>> =C2=A0=C2=A0 FmpDevicePkg: Add Last Attempt Status support to depende= ncy libs >>>> =C2=A0=C2=A0 FmpDevicePkg/FmpDeviceLib: Add Last Attempt Status to Ch= eck/Set API >>>> >>>> FmpDevicePkg/FmpDxe/FmpDxe.c | 176 +++++++++++++++++--- >>>> FmpDevicePkg/Library/FmpDependencyCheckLib/FmpDependencyCheckLib.c=20 >>>> |=C2=A0 39 +++-- >>>> FmpDevicePkg/Library/FmpDependencyCheckLibNull/FmpDependencyCheckLibN= ull.c=20 >>>> |=C2=A0=C2=A0 9 +- >>>> FmpDevicePkg/Library/FmpDependencyLib/FmpDependencyLib.c |=C2=A0 96= =20 >>>> +++++++++-- >>>> FmpDevicePkg/Library/FmpDeviceLibNull/FmpDeviceLib.c |=C2=A0 48 ++++-= - >>>> FmpDevicePkg/Test/UnitTest/Library/FmpDependencyLib/EvaluateDependenc= yUnitTest.c=20 >>>> |=C2=A0=C2=A0 7 +- >>>> FmpDevicePkg/FmpDxe/FmpDxe.h |=C2=A0=C2=A0 4 +- >>>> FmpDevicePkg/Include/LastAttemptStatus.h |=C2=A0 96 +++++++++++ >>>> FmpDevicePkg/Include/Library/FmpDependencyCheckLib.h |=C2=A0=C2=A0 8 = +- >>>> FmpDevicePkg/Include/Library/FmpDependencyLib.h |=C2=A0 44 +++-- >>>> FmpDevicePkg/Include/Library/FmpDeviceLib.h |=C2=A0 48 ++++-- >>>> FmpDevicePkg/PrivateInclude/FmpLastAttemptStatus.h |=C2=A0 80 +++++++= ++ >>>> MdePkg/Include/Guid/SystemResourceTable.h |=C2=A0 13 ++ >>>> =C2=A0 13 files changed, 575 insertions(+), 93 deletions(-) >>>> =C2=A0 create mode 100644 FmpDevicePkg/Include/LastAttemptStatus.h >>>> =C2=A0 create mode 100644 FmpDevicePkg/PrivateInclude/FmpLastAttemptS= tatus.h >>>> >>>> --=20 >>>> 2.28.0.windows.1 >>> >> >>=20 >>