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 1D6231A1E21 for ; Mon, 29 Aug 2016 00:51:44 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:Received:X-LoopCount0:X-IronPort-AV:From:To: 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=HL4U8RA0NRXjSm0TVt0GWEyZOUWe7v5od+jWAQ6ZhjvSzf4OnrjZowN3 t+5euZGV0meCo39V8HJlpNJ+jnA4vJT0T6BL5BvXFoe1M9OJ2vuy2es2Z fiwuWRKHHcV8dZUEMFxqAdLXgLNKO9KIg+VQDPRZfZK3+snyFPvX5RpUW g=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1472457104; x=1503993104; h=from:to:date:subject:message-id:mime-version; bh=Ki+rItmq6eiQxD10NVISktJqA1zmohy+m2w6YbEfvyQ=; b=HEtUxWwsEgQfzCNL05noFPJR4rsa4kk4/yb+/Z5tMCwtae9yu7hvuSlr DR3wF7Q3kEfxtJWB151dWinPwKuwtXvcR238xLMrT+GAV5N6dx+neGdWi IQmvF2x31IoKY/MF9YKvFwqvK9xTXVhrETjeRv1HJ0tybl6a05I5+goPj Y=; Received: from esa2.dell-outbound2.iphmx.com ([68.232.153.202]) by esa1.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Aug 2016 02:51:43 -0500 Received: from ausxippc106.us.dell.com ([143.166.85.156]) by esa2.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Aug 2016 13:51:43 +0600 X-LoopCount0: from 10.170.28.39 X-IronPort-AV: E=Sophos;i="5.28,595,1464670800"; d="jpg'145?scan'145,208,217,145";a="9030848" From: To: Date: Mon, 29 Aug 2016 13:21:16 +0530 Thread-Topic: [EDK2] DxeCapsuleLib returns Status Issue Thread-Index: AdH98GtsCy4QvCtoQNmxQMae1pGCQwAANJIAAPYzTiA= Message-ID: Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Dell;Classification=No Restrictions;Sublabels=; x-titus-version: 3.5.29.3 x-tituslabs-classificationhash-30: k5/vssDqmf2mveDUEIruN0MbMrDOKiJwzmozAL8RjBYDFbGlPoNlKeyljtZ83oBq1En3hwYy88aBVhBt9IpcaEkSnKMy3k/MWCCdYd+ysYzzLv6T5iRaB/HZJGdkDxrTMZUW/2LenojqmmCXZxxR6S66KK8j84BWWox4ZBAGfmszPJl39mBcPtLcf0U8Yg0Mk2wueRJamh4b56OUboiqbeTACXDYCYg9+co1PX/qywo= 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: Mon, 29 Aug 2016 07:51:44 -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@01D201F8.38564220] 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