From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=67.231.154.164; helo=dispatch1-us1.ppe-hosted.com; envelope-from=tpilar@solarflare.com; receiver=edk2-devel@lists.01.org Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id E048021196214 for ; Wed, 28 Nov 2018 02:43:40 -0800 (PST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (webmail.solarflare.com [12.187.104.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 7DEAAB0005C; Wed, 28 Nov 2018 10:43:39 +0000 (UTC) Received: from tp-desktop.uk.solarflarecom.com (10.17.20.51) by ocex03.SolarFlarecom.com (10.20.40.36) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 28 Nov 2018 02:43:36 -0800 To: "Kinney, Michael D" , "Gao, Liming" , "edk2-devel@lists.01.org" References: <3d05d3db-1a45-99f7-95ac-5bc77daf0494@solarflare.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E373119@SHSMSX104.ccr.corp.intel.com> <5003ac72-455b-3d5f-2eea-6bc6aee928ed@solarflare.com> From: "Tomas Pilar (tpilar)" Message-ID: Date: Wed, 28 Nov 2018 10:43:34 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [10.17.20.51] X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24250.005 X-TM-AS-Result: No-18.169000-4.000000-10 X-TMASE-MatchedRID: Jm7Yxmmj9OmnykMun0J1wqZCFtxq3n99lavqJJda2A+VMkyCbq23YQLT 4If2WwaeEo6iCxyJ/HFhMSBHcFZzVP4KcCyKEWS2VU3yVpaj3Qxa0OEIdxUCnhjQD3m2MCf7cGD Hv4L4COyZhDuz5mCam+A0nFd4W6KwNGfbF3CuxemNZ7kc4Uq+45sAVGimIUEK5DJ1FS+XdBNZzS O7EMl5XElzFJ+vo5FAvZLctNfuqT9JJDuM6qazTozb2GR6Ttd3KVrLOZD1BXTJBgQYFTMaLaZPV EKdG1skRFsqph676uAXEaT5uhkwzOBX8Ypq0C8lFYJUGv4DL3x4XLNBjM9D5Nvpj5+dNlQvwm/W Y6iTAFwq65xAyvkt7VBz5a8d+nMsHZ3queXVwR+hLSC6hXpJlwOWx6MQC8CD2oLGTNKlb9fzDW0 uL3HdaBH+MXG5fwux5JEhOHr9HLnNOxYbhNRG3MnUTf2MoOKYwDMmA7wK/abJ2i9a4v4pV1PWus 3yxQNWt+odoSua73aRk6XtYogiau9c69BWUTGwVnRXm1iHN1bEQdG7H66TyF82MXkEdQ77Ns/vg XavrCJXHV3H60MalXDOBYxfzhyL1dUmkpxKT1cor1fNrYIouQ== X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--18.169000-4.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24250.005 X-MDID: 1543401820-eHWeYZ2fEPqO 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 10:43:41 -0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-US Hi Mike, Thanks for looking at this. I was actually thinking of how I could contribute. I was thinking of drafting the following patches: 1. Move FmpDxe data storage into heap allocated FMP_DATA struct, retrieve using standard CR against the protocol treatment. Allocated by FmpInstall(). This might need registering FmpRemove() however. Alternatively register a ExitBootServices callback that uninstalls the FMP. 2. Create FmpDeviceInstanceLib prototype that works like FmpDeviceLib but passes a context parameter to each function. 3. Implement FmpDeviceInstanceGlobal library that pulls in FmpDeviceLib and produces a FmpDeviceInstanceLib 4. Change over FmpDxe from FmpDeviceLib to depend on FmpDeviceInstanceLib. This is not particularly urgent, but we are trying to implement FMP for our optionROM driver and it would be nice to be able to use the upstream cleanly rather than forking it in our driver. If you think the way forward seems okay, I am happy to put in the work. Cheers, Tom On 28/11/2018 01:15, Kinney, Michael D wrote: > Tom, > > Thanks for noticing this issue. I need a little > 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 >> >> 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. >> >> Cheers, >> Tom >> >> 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 >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel