Re: [edk2-devel] [PATCH v1 21/26] OvmfPkg/LoongArchVirt: Add FdtQemuFwCfgLib

["Gerd Hoffmann" <kraxel@redhat.com>]

On Wed, Apr 17, 2024 at 03:43:30PM +0800, Chao Li wrote:
> Hi Gerd,
> 
> 
> Thanks,
> Chao
> On 2024/4/17 14:59, Gerd Hoffmann wrote:
> > On Wed, Apr 17, 2024 at 10:53:21AM +0800, Chao Li wrote:
> > > Hi Gerd,
> > > 
> > > Part 2 has been be merged, I'm separating  this Lib into two serve the PEI
> > > stage and DXE stage.
> > > 
> > > Currently, This DXE library uses three global variables, and when I simulate
> > > the no-mmio version: MmioLib.c + Dxe.c + Pei.c, I can abstract some helper
> > > functions as the public functions in Mmio version.
> > > 
> > > Do you mind if I replace these three vaiables with three dynamically typed
> > > PCDs? If so, the PEI and DXE stage libraries can using  some of the same
> > > APIs.
> > What is your idea?  Let PEI discover fw_cfg, store results in PCDs, and
> > DXE will read the PCDs instead of using FdtClientProtocol to find the
> > fw_cfg?
> > 
> > Note that risc-v and arm don't need access to fw_cfg in PEI, so this
> > approach would not work for them.
> 
> No no no, I mean these two stages have their own way to get the FDT
> resouces, for example: PEI stage uses fdtlib to find the fw_cfg and the DXE
> stage uses FdtClientProtocol to find the fw_cfg, DXE will look for fw_cfg
> anyway.

Ok.  I'm wondering what the point of using PCDs is then.

> Can I submit a patch set for quick review by you? It content only four
> patches.

Sure, maybe that is the easiest way to explain ;)

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117903): https://edk2.groups.io/g/devel/message/117903
Mute This Topic: https://groups.io/mt/104859897/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-