From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.dell-outbound.iphmx.com (esa1.dell-outbound.iphmx.com [68.232.153.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 956CA1A1E2B for ; Wed, 24 Aug 2016 03:23:09 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:Received:X-LoopCount0:X-IronPort-AV:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-tituslabs-classifications-30: x-titus-version:x-tituslabs-classificationhash-30: x-titusconfig:acceptlanguage:Content-Type:MIME-Version: Return-Path; b=OEjAfpb9Rqp5d+FgZhZlhHtc8amK+PsLsD8CBZbqrwymry+yINhwGvin As+hmWGs+6nGqirw8R3utuLaVttL2Qf3juB9e5/blSiQrpgGV1X7qs4Ci y5U4Fj79wsx4dDCYJjc47B4jPHrwHvOEUbLykCPg7ttVUlQVz6vVTnAHV k=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1472034189; x=1503570189; h=from:to:cc:date:subject:message-id:mime-version; bh=vZBd+AcqKxmZhdsgSYHS5ELeTihiAtNssJppZBZku8U=; b=O0UCJVtReqBsVcJizOID1yjBQAh1kyV00AZPNXeRc7mWMAEPO9ft5iA5 +bBtQfzQNDLNnrN3zaYvZnJ5/8/uC8b5AVyKrZqkTsQOYul1TEEgXsMd+ JFkU4cCvjVhz83sWqRxzcvktavSu3XCRaiT7UwZs0SyFT4+cB4514UEmR A=; Received: from esa5.dell-outbound2.iphmx.com ([68.232.153.203]) by esa1.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Aug 2016 05:23:09 -0500 Received: from ausxippc110.us.dell.com ([143.166.85.200]) by esa5.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Aug 2016 16:23:08 +0600 X-LoopCount0: from 10.175.216.251 X-IronPort-AV: E=Sophos;i="5.28,570,1464670800"; d="jpg'145?scan'145,208,217,145";a="407222768" From: To: CC: , , Date: Wed, 24 Aug 2016 15:52:26 +0530 Thread-Topic: [EDK2] DxeCapsuleLib returns Status Issue Thread-Index: AdH98GtsCy4QvCtoQNmxQMae1pGCQwAANJIA Message-ID: Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Dell;Classification=Internal Use;External=No;Sublabels=; x-titus-version: 3.5.29.3 x-tituslabs-classificationhash-30: k5/vssDqmf2mveDUEIruN0MbMrDOKiJwzmozAL8RjBYDFbGlPoNlKeyljtZ83oBq1En3hwYy88aBVhBt9IpcaMekn1n4XLQJNDKLEq/6K970j2kx2PuaCDjOxJJGFZIhehNwp8tjzbUyS0HYYbiGJPQbHqLN0AIGvaJT5rgbZgWCIoH2hjGmQiCPtUlM2u2XZAkyQKTX+/pOZU7NzTgYUzN3/fWmeTKzhSIDz5WPuHelrFVtwj3+2ycOdsF/bx3h x-titusconfig: 1.4AMER acceptlanguage: en-US MIME-Version: 1.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: DxeCapsuleLib returns Status Issue X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 10:23:09 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dell - Internal Use - Confidential Hi EDK2 Developers, We are incorporating DxeCapsuleLib for FMP Capsule Update into our UEFI pro= duct, but we are hitting few issues as described below. In case of Capsule Update "SetImage" is randomly done for all the FMP Handl= es in case Image Type Id GUID and Image Index matches (this is expected as= there might be multiple similar hardware), but looks like the returns of e= ach FMP update is not handled. For example if there are 5 FMP handles (can be for different-different devi= ces) and assume that any particular device handle is at 3rd index, therefor= e the update goes through successfully on the 3rd attempt but since HandleC= ount value is 5 it tries further with 4th and 5th Handle. This 4th & 5th Ha= ndle attempt can fail for any of the calls within the FMP Handle "for loop"= (HandleProtocol/GetImageInfo) and hence the final status is returned as FA= ILURE to application layer. Below is the code-snippet from DxeCapsuleLib.c , in case of HandleProtocol = & GetImageInfo failure, "for" loop for Handle count is continued and the pr= evious Status value is over-written with this new return (return from Handl= eProtocol & GetImageInfo) and finally returned to application. [cid:image001.jpg@01D1FE1F.828C9E70] Proposed Solution:- Can ProcessFmpCapsuleImage() have an extra OUT parameter which gives the li= st of all successful FMP Handles along with the updated GUID values, so tha= t any application can make the judgment of Update SUCCESS/FAILURE based on = FMP Handle and proceed accordingly at application layer. Regards, Ankit Singh