From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (NAM10-DM6-obe.outbound.protection.outlook.com [40.92.41.23]) by mx.groups.io with SMTP id smtpd.web10.126767.1597977461455193588 for ; Thu, 20 Aug 2020 19:37:41 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@outlook.com header.s=selector1 header.b=k+JLNfFk; spf=pass (domain: outlook.com, ip: 40.92.41.23, mailfrom: spbrogan@outlook.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Jf5IwHTXtgwIokwjhuWzIM7BUxu2wqTqYdHqeHQMDCTt3bMAXMMCF5K+96aTQ8osF33/R3OzaQl5lB2/slKRaxNof/xAdBPPkAQeTsOMb/ifkjBUGsfERw+Bb4hBsGzm8d1Bi9npq0cOuckdij/SjgRbSW1H11W8XgnVSvM3Kz+yYBgWHVK//VfRE0dowi3FO25kfhrcFVGD6keWj8kRNciy3DRXEnNVjknPx6OqzaOZtKvOEf8EE6v6HwhRpHth3IbTCmhIIryWJYMmTHDpEUt9ZG0WAdMZaMQ3PQuW5BLuPoMnNmciKNQc52/8a1DNKlnAp/Mb25VAms0DD60xWg== 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=nnGb4IYU9/HodRZCx+8FCDYLp01uswdlzNKEW9WTNzs=; b=T0CNLMB5kgeNx8Tk1/Kr8HtkF04xHGBZVmfGTBU8xlZhEulD08KfAaMAHMmPohsh/w8eylRacwSH3uZXesQ5RPf3VwXeOcIYHzaan05diRwwG0i42+/Qdx+A+z7Oyd6lZq7+KFJiZq1SDX6/RbRLut/XRLNAmGpbmz8VvyPD1vgtdee3WWzJ38/O+cp9wtRn6YMDjGkJu2SQCaSjK/hKLZpK11qoJV9Htwkz1mvcZxDOnr1XgoyxsXDFu0BwGWQXuaYxRsibFZQ0kLbk37gUkxjTa2mRKjiPk+W4UdDIAHzWIILb+/dhFIfwuongV6fh8OWDE2ye0S/KfPRL/kQZeA== 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=nnGb4IYU9/HodRZCx+8FCDYLp01uswdlzNKEW9WTNzs=; b=k+JLNfFkvyuu3bjBAxZ+5R5sM8Yk3rYZFg8brdx53i54y1V7D9flFQxMxGqQ41dbPI7dsNE83XC7WkDcnsTzn/WtxwTICvTuag/XndjaRDPktXQUDMvAQSh/sqrcfVRRS/TAPeWJtr6oqwx5cX+b/39UN3tseG225v8HTRkyIqV2guI4c5jsSh9lfiq23ZHHrhhdibfM4/0DboV1XfKgdyfSFIiGWawzaN4XE+dUar30H6xYeWDkMfGeDAVxH9TFsUG+8sRFd5mPXN5IAUD3JPj3sJ+NXS6BXhWzxuAqNIL6kHuB64X7z23vO5G+vaI99ymLuLyBz4KJAfm8HDUF4w== Received: from MW2NAM10FT046.eop-nam10.prod.protection.outlook.com (2a01:111:e400:7e87::4e) by MW2NAM10HT230.eop-nam10.prod.protection.outlook.com (2a01:111:e400:7e87::93) 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 02:37:39 +0000 Received: from BN8PR07MB6962.namprd07.prod.outlook.com (2a01:111:e400:7e87::50) by MW2NAM10FT046.mail.protection.outlook.com (2a01:111:e400:7e87::205) 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 02:37:39 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:CD29ABC87D071DC95D72152893E085763FF7CE413728989B38DB515E974AFC37;UpperCasedChecksum:EF0B7C5391741FFF04DAC7316E09CF4D977321ADA32DA5281ABA86217900BB88;SizeAsReceived:9192;Count:49 Received: from BN8PR07MB6962.namprd07.prod.outlook.com ([fe80::b1be:f3e4:f6e:66c3]) by BN8PR07MB6962.namprd07.prod.outlook.com ([fe80::b1be:f3e4:f6e:66c3%4]) with mapi id 15.20.3305.026; Fri, 21 Aug 2020 02:37:39 +0000 Subject: Re: [edk2-devel] [PATCH v3 0/6] Extend Last Attempt Status Usage To: devel@edk2.groups.io, michael.kubacki@outlook.com, "Kinney, Michael D" CC: "Gao, Liming" , "Jiang, Guomin" , "Xu, Wei6" , "Liu, Zhiguang" References: From: "Sean" Message-ID: Date: Thu, 20 Aug 2020 19:37:31 -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: MWHPR04CA0045.namprd04.prod.outlook.com (2603:10b6:300:ee::31) To BN8PR07MB6962.namprd07.prod.outlook.com (2603:10b6:408:d6::11) Return-Path: spbrogan@outlook.com X-Microsoft-Original-Message-ID: <54d08535-71e4-212c-64af-35c66ac30e80@outlook.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from 255.255.255.255 (255.255.255.255) by MWHPR04CA0045.namprd04.prod.outlook.com (2603:10b6:300:ee::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.25 via Frontend Transport; Fri, 21 Aug 2020 02:37:38 +0000 X-Microsoft-Original-Message-ID: <54d08535-71e4-212c-64af-35c66ac30e80@outlook.com> X-TMN: [1L4H7Jx/W5CQ1IurET99LF5ZgqWjM+Ch] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 49 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: fcaeef01-ec87-4745-c588-08d8457b2bd3 X-MS-Exchange-SLBlob-MailProps: inBjZRGSCZkw9Y2zTNWkXRyCb5S4gAmSUdzWIydRMN2vYM8DMLY3Cd+BzkPuxGII8xhmmE/fn2S2UJ2TL0Qah0UTuUs54Bj+9JhD3B8uQtkPshrYmG7tbfpD7TiLhz/dBj6XsiWBmZMSLvJi5fQYgTXcINMKqwSz19PVKBF4MM9W+cDY/dmO0+2Es5noEhm1gqImm/MSAl3Dd+ctJjpJjM4t05OeYwexO5wzggfY9+kE3O82nmzgNnSCuOiKZcCN8TvsHS+o4vECBmTIaXahQFV3RDjWgsa2SNUSFP4ozYV0NjURadl2jwCsJFPoD/kMbM2k8igZWRRBxgxZ3PHzbZ3l4ORWpk6S0Gn1pPuQcs0d71CAwbH8Gk+6f3e/74Tof3FEE2h2zrO1zbtGFyrE4AaxFr5O+s/WFP8GX3hyyfYCgHFZCOPaCVMyEGlCOtQI42vybyjthVDqXBW5AlGCZvMLoiSG7yKjVlqCwUUXOA+xGkdYRCq2vEP0lEx5kgw4lTXrx5qPPbTj+SEYNul+0ZEN1RnVEiMjUAO0ImU5rBR+eomKiqg+vX4kPG9w7v6If7t6DnWLXCMpFOr0x3NeVXPHSXdL9JaFTU7YUMzY5lZq/bTGfJAmm3aTRExgSWHbSO7TakQNNQ4oJSzYbePn9OV6ESvjBwy5yh4//sFV4IAKneYk6vmnF48PmY6InZXXNfgLM+cFQuRxB4vkmK8OULl8lXAxrAQ6oUeF/By4MZfzBY5oTFrHGojyKiTxtrDojlBseMNhYzC1C7vw8MbX2nu8fYXWXfGc4Rl4nn4ZaFC289jtYLB3K1QIdEa/H114uIJXs9j0EFqAK9HQYzDhob/q2yEql2zSRBZo3qyDVrctZYEEXxndaJHBt7SuDLvyEJC1ePSQCE/RL/9USOe6yhb8rs9lPZVInTYT0K2lU+n/DHTmYdlF80yJMpzH6aLVqJeOs2hhpF2arX/SIjI9OQ== X-MS-TrafficTypeDiagnostic: MW2NAM10HT230: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ee9RbFqm0gZyJCqrGGZAeyHK6b4nxxfJvZvmjWjgrc2Iwyhhw6N6xfCOVcMuBmV0VXmRpjNst4L7Z3K2jzkRkLQ69Vab20IEixbQ8Q8nM914ZgVRQEa0XDYBrhMXDZ/EYbiOBQo2lhAS6KWxzN+phMY/OireX2bcrrTHpRNkf2Zb9vdqjesUGogZ+GwM8yOmeYBiwOjL9aBKR2nKXDFffZOraEFc3Y++kzNfWTCouAsmKrxNV4+RtDFIAaxwCZSG X-MS-Exchange-AntiSpam-MessageData: 7iT0FF7lFLwPDclkC19CPrAYj74W5UVpuCBM3k7fsXOuTVihSeCx8MAi4sUVQ04uXie1lAb4asvVlK+gwM2Afh0YpXt9ySBGsJ9NmpmuMsHkNXQjFTlZYx/VKAkAbpTp7QwTbtHnMLNx2puHX5tL/A== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fcaeef01-ec87-4745-c588-08d8457b2bd3 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Aug 2020 02:37:39.4614 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-AuthSource: MW2NAM10FT046.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: MW2NAM10HT230 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Michael, #1 I would suggest calling out the sub-range 0x10A0 | 0x17FF -- Free for Library Implementations of FmpDevicePkg 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). Now is 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. To me this is preferred. 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. Not only that, it leads to nearly everyone ignoring the=20 change. There is no need for this change to be a multi-year integration= =20 or cause extra development of shims and translation functions. The API=20 change is pretty easy. The implementation can choose to to avoid the=20 new ranges and just set the value to 1 (FMP unknown error). This would=20 match the behavior of today. Obviously i believe it would better to=20 take the extra time to create unique ranges for each of your libs. Also= =20 note that if anyone is doing third party binary integration this is not=20 a breaking change. This only breaks for those doing a src build. Thanks Sean On 8/20/2020 6:25 PM, Michael Kubacki wrote: > Hi Mike, >=20 > 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? >=20 > The ranges would then be defined as follows: >=20 > 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 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 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 insta= nces 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 | >=20 > Also, I don't see a problem with removing the length defines and=20 > directly specifying min/max defines for each range. >=20 > 2.) I understand the compatibility concern but as you noted it is=20 > cleaner to maintain a single interface. I believe making the transition= =20 > to the new API will only become more difficult in the future as it may= =20 > go unnoticed resulting in implementations that don't implement support= =20 > for this capability leading to an increasing amount of future effort to= =20 > do work that could be done now. Perhaps we could get thoughts from=20 > others as well? >=20 > 3.) I will update these to return back an expected value. >=20 > Thanks, > Michael >=20 > 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 FMP= , there are no=20 >> 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 de= fines for the=20 >> length of >> =C2=A0=C2=A0=C2=A0 each range is hard to read, and I do not think there= 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/m= ax defines for=20 >> each range >> =C2=A0=C2=A0=C2=A0 for a total of 6 #defines.=C2=A0 I do not expect ran= ges (once defined)=20 >> to change in >> =C2=A0=C2=A0=C2=A0 length, and the most that might happen in the future= is adding new=20 >> 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 existin= g implementations=20 >> will have >> =C2=A0=C2=A0=C2=A0 to update their lib implementations to be compatible= with this new=20 >> version. >> =C2=A0=C2=A0=C2=A0 I would be slightly cleaner to introduce new APIs wi= th support for=20 >> the >> =C2=A0=C2=A0=C2=A0 vendor specific last attempt status codes.=C2=A0 The= n update all libs=20 >> to produce >> =C2=A0=C2=A0=C2=A0 both the existing APIs and the new APIs (The old API= s can call the=20 >> new APIs). >> =C2=A0=C2=A0=C2=A0 Then update FmpDxe to use the new APIs.=C2=A0 This w= ould be 3 patch=20 >> series. >> =C2=A0=C2=A0=C2=A0 If FmpDxe never calls the old APIs, then we could (a= t a future date) >> =C2=A0=C2=A0=C2=A0 delete the old APIs from the lib class and the lib i= mplementations=20 >> 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 imple= mented >>> =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 with= more >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 completeness providing length, min, and= 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/FmpL= astAttemptStatus.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 though= 0x4000 is defined in >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the UEFI specification. The length is 0= x4000 but the max >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 allowed value should be 0x3FFF. This ch= ange was made now to >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 prevent implementation compatibility is= sues in the future. >>> =C2=A0=C2=A0 4. Included "DEVICE" in the following macro name to clear= ly >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 associate it with the FmpDeviceLib libr= ary class: >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LAST_ATTEMPT_STATUS_DEVICE_LIBRARY_ERRO= R_xxx >>> =C2=A0=C2=A0 5. Included a map to help the reader better visualize the= 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 sta= tement stating that new >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 codes should be added onto the end of r= anges 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 FmpDevic= eLib >>> =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 fo= r >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 different memory allocations in CheckFm= pDependency () in >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FmpDependencyLib. Each potential alloca= tion 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 (pat= ch 2) >>> =C2=A0=C2=A0 2. Move LastAttemptStatus.h from Include to PrivateInclud= e >>> =C2=A0=C2=A0 3. Correct patch 1 subject from "FmpDevicePkg" to "MdePkg= " >>> >>> 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 St= atus >>> =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 dependen= cy libs >>> =C2=A0=C2=A0 FmpDevicePkg/FmpDeviceLib: Add Last Attempt Status to Che= ck/Set API >>> >>> =20 >>> FmpDevicePkg/FmpDxe/FmpDxe.c = =20 >>> | 176 +++++++++++++++++--- >>> =20 >>> FmpDevicePkg/Library/FmpDependencyCheckLib/FmpDependencyCheckLib.c = =20 >>> |=C2=A0 39 +++-- >>> =20 >>> FmpDevicePkg/Library/FmpDependencyCheckLibNull/FmpDependencyCheckLibNu= ll.c =20 >>> |=C2=A0=C2=A0 9 +- >>> =20 >>> FmpDevicePkg/Library/FmpDependencyLib/FmpDependencyLib.c = =20 >>> |=C2=A0 96 +++++++++-- >>> =20 >>> FmpDevicePkg/Library/FmpDeviceLibNull/FmpDeviceLib.c = =20 >>> |=C2=A0 48 ++++-- >>> =20 >>> FmpDevicePkg/Test/UnitTest/Library/FmpDependencyLib/EvaluateDependency= UnitTest.c=20 >>> |=C2=A0=C2=A0 7 +- >>> =20 >>> FmpDevicePkg/FmpDxe/FmpDxe.h = =20 >>> |=C2=A0=C2=A0 4 +- >>> =20 >>> FmpDevicePkg/Include/LastAttemptStatus.h = =20 >>> |=C2=A0 96 +++++++++++ >>> =20 >>> FmpDevicePkg/Include/Library/FmpDependencyCheckLib.h = =20 >>> |=C2=A0=C2=A0 8 +- >>> =20 >>> FmpDevicePkg/Include/Library/FmpDependencyLib.h = >>> |=C2=A0 44 +++-- >>> =20 >>> FmpDevicePkg/Include/Library/FmpDeviceLib.h = >>> |=C2=A0 48 ++++-- >>> =20 >>> FmpDevicePkg/PrivateInclude/FmpLastAttemptStatus.h = =20 >>> |=C2=A0 80 +++++++++ >>> =20 >>> 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/FmpLastAttemptSt= atus.h >>> >>> --=20 >>> 2.28.0.windows.1 >> >=20 >=20 >=20