From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (NAM12-DM6-obe.outbound.protection.outlook.com [40.92.22.25]) by mx.groups.io with SMTP id smtpd.web11.2138.1598642451888413760 for ; Fri, 28 Aug 2020 12:20:52 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@outlook.com header.s=selector1 header.b=PV/stUrI; spf=pass (domain: outlook.com, ip: 40.92.22.25, mailfrom: michael.kubacki@outlook.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZjJc5G6qaCGRfdIeONZ642tyeuptWyIGIG0ddQew7ZatDmqoMdveyg1MygeVwb8+D1aS7IVrvR91xjiu0zVzIuSnuYhp0F4aq4HB7eeRL+KDZ/lI2N0InUBCG5AJzo5u2cg3mqpGUO2oSESfhKkfMimAp40+2Ack1IOqDCfdvyAtirVVjkH4g3KT8OwEw66QQBIkMKWpjddRCu89FiW8OJnl5AKAtvcj/QRoTHO97VdJBm8+ugEs+5CvpATixlivbijfHIwlvPNZCAcKyG0IyllVcD40ahBsoZjbZxuN5wRsDW0FSv5024w40KjROTa5D5W28lmoXolQJKVrWY4LsA== 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=ku6nLZvqcrxp2jDyPf7BWNP//H+6iIllyzYM5F4CgRY=; b=XmoKgytAvOQxCfbwcaacDlQUqd17rGVZAGVG7jeDZ1P+ZzJyzxIKb8zOo9kZan70bwMGt1+/FIG2p3S0pnwGin19b7nMhsKYArHnbaIkCoyrcXcwhT9G2AqM5pc3y2CBe9X/RweNl2VAHEipX++ayLe5rKaxvccxxH8Uxt3RJA/oSInjQFq/8mpSYEsRC5OXyOxqK71gHk+sYp7kuZZVU+5OuQ/OYJiwcp33gFe0lFRoDt3kxq1IBp6HG5YYvhnpvHTMOqjmet0GYbCXvgqD9JTLMQurT/FUMN+DpN7t1Oar4pQYPgmvcTUdfFjRY4aJxkWRQFvwtrzEOsgDLgYrXg== 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=ku6nLZvqcrxp2jDyPf7BWNP//H+6iIllyzYM5F4CgRY=; b=PV/stUrIIT+xrKXK1yLvTtiD7JlWkAXYE0wJAlSByS/Ru+kPVHiE5Q/XeCeimb/kft4ri6QtP8y9wykh0F3dlTxyEN9I42HExP39a66milq1y73Pa3H3Zn3ixhQ8ldGTCeb1FExEGB5HMtNwh0xrqsDA517lnjgvsRdCK49bZl1FE7GlHxCudTpEYeT5lmiWq7biqD8kgbxpgXA2MUMKqNwy7FgCnDIX633zxWhlWrav/euwPsmwoxOjeq12npFIS+TkktmFGsfAcAD7zHBedFGhy3xv+Pt06NkjM+LftNsREtIW3tHVPBLWrXFWHoiMVTBqUM7WXdC1V76Af6hT6g== Received: from DM6NAM12FT044.eop-nam12.prod.protection.outlook.com (2a01:111:e400:fc64::4e) by DM6NAM12HT049.eop-nam12.prod.protection.outlook.com (2a01:111:e400:fc64::252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.7; Fri, 28 Aug 2020 19:20:50 +0000 Received: from MWHPR07MB3440.namprd07.prod.outlook.com (2a01:111:e400:fc64::44) by DM6NAM12FT044.mail.protection.outlook.com (2a01:111:e400:fc64::204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.7 via Frontend Transport; Fri, 28 Aug 2020 19:20:50 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:99DF019EB1E69B583D661ACAADADA5A661E3D6F5E834BA15482FD0FA1EBD8D2F;UpperCasedChecksum:D8E86124DD5A9D12EF62FF5998A9BF26067CCD19DC34FD146CC57658018DA911;SizeAsReceived:9404;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.031; Fri, 28 Aug 2020 19:20:50 +0000 Subject: Re: [edk2-devel] [PATCH v3 0/6] Extend Last Attempt Status Usage From: "Michael Kubacki" To: Sean Brogan , devel@edk2.groups.io, "Kinney, Michael D" CC: "Gao, Liming" , "Jiang, Guomin" , "Xu, Wei6" , "Liu, Zhiguang" References: Message-ID: Date: Fri, 28 Aug 2020 12:20:49 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 In-Reply-To: X-ClientProxiedBy: MWHPR01CA0031.prod.exchangelabs.com (2603:10b6:300:101::17) To MWHPR07MB3440.namprd07.prod.outlook.com (2603:10b6:301:69::28) Return-Path: michael.kubacki@outlook.com X-Microsoft-Original-Message-ID: <91838e35-485f-10a3-9aca-1269cba418e0@outlook.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from 255.255.255.255 (255.255.255.255) by MWHPR01CA0031.prod.exchangelabs.com (2603:10b6:300:101::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.19 via Frontend Transport; Fri, 28 Aug 2020 19:20:49 +0000 X-Microsoft-Original-Message-ID: <91838e35-485f-10a3-9aca-1269cba418e0@outlook.com> X-TMN: [ScRTQezp7M7Q3qp6ZontIa1pm91BDuc+kSJxJ+YIRjHGq66eD7cSe1mD/Z/gr4Be] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 49 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 6711e49e-0eae-4d86-569c-08d84b8778e4 X-MS-Exchange-SLBlob-MailProps: jGdi06XMWgAH5WinNJwh4Xsnpq9U0RNdCuSl3fcRd+2q6hn8/0XzaI/DFn4wE9TcqECQQbHeU3Xhds6EYwpgjyd8LTR1HEZ3z5ip4EZu5fFjlK0YvamJsNy0zhwrkbitI/aU5h8H797olTUgMS2WZM5zYlrjPmI3cQkMgLdKUDV/s/k+LwcYzt+bbutp5Ti8+gmeJWezB7nMHDU11+VA08u2gtcuE9QQR5tE4Qr2QRYqrGpxocQhUmknHhTCrGWI/m31Uz7A7gqJ7E6tYdC0H0zd+lahv3e2qw+EVxAWgCfZQrbqSFMi7N+wX5SK1Kbw6gb3VDN9MDiqxh5ADMlBv71ybLg7obhbHaSsMhukYdaY2tVnbep9LRAoMqVTrqH7vcBCRMJgOyGjyKJmy7x5bdNL9xDkZym4E26LvvsX3vjMryp+t6x7TMOYyWIvqtmbHuivpZkGczr+yy1x3OuSocdOJpwWy6mpdAe6EANYDQT6vOj1TSsdymeA0YkBod389FaZZ1QJ4FmM8C+7FscB7PAKC9f/qb4flHAzGDyx7nLJ/mAdThWSpiLv1rTIXLkEcDcNYgccWgF/+rLi5GC4TG/i+5aSB4EdrlX6BqlDaXNlspETA/y7zEcmVqLOLL7zWdIsxWCOIxMXfdncF/6g/IUpo3GmMD/0Wy2C6jJjjkD1TrHfmyp6OVbyQjoamKpJGdwv0Skxm1/4sA/Kg0PradlFBgaYPOO0gUn0PKdAwianDf73LwtQxZM7E1G+bAg22drv/QhmvaWk+Tv+/L/Oyg4WG++NO5oBcl610HBfyxQQ3XSNAmzPLH1url7Q5CDl2+p0+FuzJlTsr78PuJAQXPFUc3bx+WMb803TX6BPUS+tqOismmbUU1sAn8C5jNwt28Y2YmZl8qMglMzkv23IJ/JohxPb49tM5G0ZMVYmVsaLUevhYC57+asrKn+RkFHVZjP2fNB56PgO2EZSoPCaUh0vDpoBQnCU X-MS-TrafficTypeDiagnostic: DM6NAM12HT049: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: +E0fw8ftUftu8tN9DvfUB7iPZm744t7YxC8JWCVx9On4rcRVZy92rAczbmi9Z6NFQgUiEGKxof0HZK3yeMS8ej5LdY0hY9lITekhBbf2ApDizCuqZQVtnJTW3PLOpzEDPLxZmAzEv6Du6IQU8oZvRBs8fgm4r+bRzTxpR5PJKXWP/Kt+OlnoQzGPVZv0DJx78C+Y7DeCyGn61uaNnQ5G8miGq8ECcLIne+m6QRGbAYeMn7g8t9jd6ZG6kgLMlw0c X-MS-Exchange-AntiSpam-MessageData: zYdCI129aCio7gbYDp2yjCmiFa/7PTAcLcpDASc2Zq2l2CAL5n4hqg5LUVIjbVXD8FWL9GpU78pJYEaxl7dKviM9Af+H6fVP5dy5gnB/VyqCt0SBFd5/9XpOU3s3BD1cOYnUVHyRuO1QxTdzgNhj8Y1eZai+NLvWqhxJlAJ95FkfDHE7Ws/BWppShC9gaW6i//ss009Mge+hManJNpZHYA== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6711e49e-0eae-4d86-569c-08d84b8778e4 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Aug 2020 19:20:49.8410 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-AuthSource: DM6NAM12FT044.eop-nam12.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: DM6NAM12HT049 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Mike, We've stated a few reasons we prefer to change the library API now. Do=20 you find that acceptable for v4? Thanks, Michael On 8/21/2020 2:25 PM, Michael Kubacki wrote: > Hi Sean, >=20 > Thanks for the feedback. >=20 > #1 - I will include both suggestions in v4. >=20 > Thanks, > Michael >=20 > On 8/20/2020 7:37 PM, Sean Brogan wrote: >> Michael, >> >> #1 >> I would suggest calling out the sub-range >> >> 0x10A0 | 0x17FF=C2=A0 -- Free for Library Implementations of FmpDeviceP= kg >> >> 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. >> >> >> #2 >> Given that edk2 does not have any real FmpDeviceLibs (only instance is= =20 >> FmpDevicePkg\Library\FmpDeviceLibNull\FmpDeviceLibNull.inf).=C2=A0 Now = is=20 >> the best time to make a breaking change. It is very common for=20 >> downstream code repositories to integrate edk2 and be forced to make=20 >> changes associated with the new integration.=C2=A0 To me this is=20 >> preferred.=C2=A0 A build break is easy to resolve. When functionality= =20 >> changes or new features are added but don't cause a break this is more= =20 >> difficult to integrate correctly.=C2=A0 Not only that, it leads to near= ly=20 >> everyone ignoring the change.=C2=A0 There is no need for this change to= be=20 >> a multi-year integration or cause extra development of shims and=20 >> translation functions.=C2=A0 The API change is pretty easy.=C2=A0 The= =20 >> implementation can choose to to avoid the new ranges and just set the= =20 >> value to 1 (FMP unknown error).=C2=A0 This would match the behavior of= =20 >> today.=C2=A0 Obviously i believe it would better to take the extra time= to=20 >> create unique ranges for each of your libs.=C2=A0 Also note that if any= one=20 >> is doing third party binary integration this is not a breaking=20 >> change.=C2=A0 This only breaks for those doing a src build. >> >> Thanks >> Sean >> >> >> >> >> >> >> 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 dependencie= s (e.g. FmpDependencyLib)=C2=A0 | >>> 0x1800=C2=A0=C2=A0=C2=A0 | 0x1FFF=C2=A0=C2=A0=C2=A0 | FmpDeviceLib ins= tances implementation=C2=A0=C2=A0=C2=A0=C2=A0 | >>> 0x2000=C2=A0=C2=A0=C2=A0 | 0x3FFF=C2=A0=C2=A0=C2=A0 | Unused. Availabl= e 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 F= MP, there are=20 >>>> no ranges available. >>>> =C2=A0=C2=A0=C2=A0 Should we limit the FmpDeviceLib to a smaller rang= e to support=20 >>>> future expansion? >>>> >>>> =C2=A0=C2=A0=C2=A0 Also, the style of LastAttemptStatus.h with extra = defines for=20 >>>> the length of >>>> =C2=A0=C2=A0=C2=A0 each range is hard to read, and I do not think the= re 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 r= anges (once=20 >>>> defined) to change in >>>> =C2=A0=C2=A0=C2=A0 length, and the most that might happen in the futu= re 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 fo= r the vendor=20 >>>> specific >>>> =C2=A0=C2=A0=C2=A0 last attempt status.=C2=A0 It does mean that exist= ing implementations=20 >>>> will have >>>> =C2=A0=C2=A0=C2=A0 to update their lib implementations to be compatib= le with this=20 >>>> new version. >>>> =C2=A0=C2=A0=C2=A0 I would be slightly cleaner to introduce new APIs = with support=20 >>>> for the >>>> =C2=A0=C2=A0=C2=A0 vendor specific last attempt status codes.=C2=A0 T= hen update all libs=20 >>>> to produce >>>> =C2=A0=C2=A0=C2=A0 both the existing APIs and the new APIs (The old A= PIs 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=20 >>>> 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 valu= e? >>>> >>>> =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 imp= lemented >>>>> =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 wi= th more >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 completeness providing length, min, a= nd max values. >>>>> =C2=A0=C2=A0 2. Moved the actual Last Attempt Status code assignment= s to a >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 private header file PrivateInclude/Fm= pLastAttemptStatus.h. >>>>> =C2=A0=C2=A0 3. Changed the value of >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LAST_ATTEMPT_STATUS_ERROR_UNSUCCESSFU= L_VENDOR_RANGE_MAX >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to 0x3FFF instead of 0x4000 even thou= gh 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 = change was made now to >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 prevent implementation compatibility = issues in the future. >>>>> =C2=A0=C2=A0 4. Included "DEVICE" in the following macro name to cle= arly >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 associate it with the FmpDeviceLib li= brary class: >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LAST_ATTEMPT_STATUS_DEVICE_LIBRARY_ER= ROR_xxx >>>>> =C2=A0=C2=A0 5. Included a map to help the reader better visualize t= he 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 enu= m in >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FmpLastAttemptStatus.h. An explicit s= tatement 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 FmpDev= iceLib >>>>> =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 = for >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 different memory allocations in Check= FmpDependency () in >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FmpDependencyLib. Each potential allo= cation 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 (p= atch 2) >>>>> =C2=A0=C2=A0 2. Move LastAttemptStatus.h from Include to PrivateIncl= ude >>>>> =C2=A0=C2=A0 3. Correct patch 1 subject from "FmpDevicePkg" to "MdeP= kg" >>>>> >>>>> 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 = Status >>>>> =C2=A0=C2=A0=C2=A0=C2=A0 capability >>>>> =C2=A0=C2=A0 FmpDevicePkg/FmpDxe: Improve set image path Last Attemp= t Status >>>>> =C2=A0=C2=A0=C2=A0=C2=A0 granularity >>>>> =C2=A0=C2=A0 FmpDevicePkg: Add Last Attempt Status support to depend= ency libs >>>>> =C2=A0=C2=A0 FmpDevicePkg/FmpDeviceLib: Add Last Attempt Status to C= heck/Set API >>>>> >>>>> FmpDevicePkg/FmpDxe/FmpDxe.c | 176 +++++++++++++++++--- >>>>> FmpDevicePkg/Library/FmpDependencyCheckLib/FmpDependencyCheckLib.c= =20 >>>>> |=C2=A0 39 +++-- >>>>> FmpDevicePkg/Library/FmpDependencyCheckLibNull/FmpDependencyCheckLib= Null.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/EvaluateDependen= cyUnitTest.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=20 >>>>> FmpDevicePkg/PrivateInclude/FmpLastAttemptStatus.h >>>>> >>>>> --=20 >>>>> 2.28.0.windows.1 >>>> >>> >>>=20 >>>