From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=192.55.52.120; helo=mga04.intel.com; envelope-from=michael.d.kinney@intel.com; receiver=edk2-devel@lists.01.org Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) (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 7678321A00AE6 for ; Tue, 27 Nov 2018 17:15:19 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Nov 2018 17:15:18 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,288,1539673200"; d="scan'208";a="277890809" Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by orsmga005.jf.intel.com with ESMTP; 27 Nov 2018 17:15:18 -0800 Received: from orsmsx163.amr.corp.intel.com (10.22.240.88) by ORSMSX104.amr.corp.intel.com (10.22.225.131) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 27 Nov 2018 17:15:18 -0800 Received: from orsmsx113.amr.corp.intel.com ([169.254.9.125]) by ORSMSX163.amr.corp.intel.com ([169.254.9.34]) with mapi id 14.03.0415.000; Tue, 27 Nov 2018 17:15:18 -0800 From: "Kinney, Michael D" To: "Tomas Pilar (tpilar)" , "Gao, Liming" , "edk2-devel@lists.01.org" , "Kinney, Michael D" Thread-Topic: [edk2] FmpDeviceLib Thread-Index: AQHUhlYCaZxMCVzSBUiUaTtlcFUjYqVkNeeAgAAN5QCAAAF3gIAAHTIA Date: Wed, 28 Nov 2018 01:15:17 +0000 Message-ID: References: <3d05d3db-1a45-99f7-95ac-5bc77daf0494@solarflare.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E373119@SHSMSX104.ccr.corp.intel.com> <5003ac72-455b-3d5f-2eea-6bc6aee928ed@solarflare.com> In-Reply-To: <5003ac72-455b-3d5f-2eea-6bc6aee928ed@solarflare.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.22.254.138] MIME-Version: 1.0 Subject: Re: FmpDeviceLib X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2018 01:15:19 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tom, Thanks for noticing this issue. I need a little=20 time to evaluate this use case and see what changes are required to make this work for a UEFI driver that manages many controllers. Thanks, Mike > -----Original Message----- > From: edk2-devel [mailto:edk2-devel- > bounces@lists.01.org] On Behalf Of Tomas Pilar (tpilar) > Sent: Tuesday, November 27, 2018 7:29 AM > To: Gao, Liming ; edk2- > devel@lists.01.org > Subject: Re: [edk2] FmpDeviceLib >=20 > Okay, so I just noticed that FmpDxe is full of module > globals including the image descriptor, so it > necessarily requires that the driver that includes it as > a library can only ever control one controller. >=20 > Cheers, > Tom >=20 > On 27/11/2018 15:23, Tomas Pilar (tpilar) wrote: > > > > On 27/11/2018 14:33, Gao, Liming wrote: > >> Tom: > >> FmpDeviceLib can use UEFI driver model/driver > binding protocol so it can install FMP on its device > handle during the BDS/Device connection phase. It can > implement RegisterFmpInstaller() to install FMP protocol > in its device handle. In this way, FmpDeviceLib is like > UEFI driver with UEFI driver binding protocol. > >> > >> Thanks > >> Liming > > Hi Liming, > > > > Sure, so now I can install FMP onto my > ControllerHandle. Say that someone gets the FMP and > calls GetImageSize. The FmpDxeLib does some checks and > then it calls FmpDeviceLibGetImageSize() with no context > parameter. This method is supposed to be implemented by > me, the driver writer, but how is the code in this > method meant to know which Controller are we getting the > image size from? > > > > So maybe I can define some module globals, declare > them in a cross include file, include that in my driver > and and have the driver populate the module globals > during probe. This immediately limits the usefulness by > requiring that each driver only ever drives one > controller. > > > > And then you consider how to do a SetImage without > being even given the Handle of the Controller. Do you > stuff the controller handle into a module global > parameter that gets populated during the BDS phase? > > > > I guess you could enumerate all FMP instances, see > which one of them advertises your ImageTypeId and get > the handle that the FMP is installed on that way. But > that seems rather insane and would cause issues if you > have two of the same device in the platform, unless you > check the HardwareInstance as well? This seems insane. > > > > Cheers, > > Tom > > > >>> -----Original Message----- > >>> From: edk2-devel [mailto:edk2-devel- > bounces@lists.01.org] On Behalf Of Tomas Pilar (tpilar) > >>> Sent: Tuesday, November 27, 2018 9:26 PM > >>> To: edk2-devel@lists.01.org > >>> Subject: [edk2] FmpDeviceLib > >>> > >>> Hi all, > >>> > >>> I am looking at using FmpDxeLib so I need to > implement the FmpDeviceLib. However, it seems like the > library functions do not take any > >>> private struct as a parameter, so I am struggling to > figure out how to read information off the hardware. > FmpDxe does not even pass its > >>> created protocol instance when calling the library > functions, leading me to believe that the only way to do > this is to assign a pointer to > >>> private struct during library construction, but that > means that a driver that uses the code can only ever > service a single controller. > >>> > >>> Can you offer any insights? > >>> > >>> Cheers, > >>> Tom > >>> _______________________________________________ > >>> edk2-devel mailing list > >>> edk2-devel@lists.01.org > >>> https://lists.01.org/mailman/listinfo/edk2-devel >=20 > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel