Re: [edk2-devel] [PATCH] MdeModulePkg/PciHostBridge: Add support for driver binding
Ray, Would you prefer this sort of use would be done by an extra dispatch after the wait for everything being completed and the connect controller call in BDS as opposed to the driver binding approach? Basically using a depex on the library as we are currently doing. -Jeff > -Original Message- > From: Jeff Brasen > Sent: Friday, June 30, 2023 9:57 AM > To: Ni, Ray ; devel@edk2.groups.io > Cc: Wang, Jian J ; Gao, Liming > ; Wu, Hao A > Subject: RE: [PATCH] MdeModulePkg/PciHostBridge: Add support for driver > binding > > > > > -Original Message- > > From: Ni, Ray > > Sent: Thursday, June 29, 2023 9:59 PM > > To: Jeff Brasen ; devel@edk2.groups.io > > Cc: Wang, Jian J ; Gao, Liming > > ; Wu, Hao A > > Subject: RE: [PATCH] MdeModulePkg/PciHostBridge: Add support for > > driver binding > > > > External email: Use caution opening links or attachments > > > > > > > -Original Message- > > > From: Jeff Brasen > > > Sent: Friday, June 30, 2023 11:21 AM > > > To: Ni, Ray ; devel@edk2.groups.io > > > Cc: Wang, Jian J ; Gao, Liming > > > ; Wu, Hao A > > > Subject: RE: [PATCH] MdeModulePkg/PciHostBridge: Add support for > > > driver binding > > > > > > Not sure why the patch failed to apply I'll see if there is > > > something wrong with my gitconfig tomorrow. The path you suggested > > > below is exactly what our current implementation does. However, I am > > > trying to make our pcie controller driver do async initialization so > > > that using a depex is less ideal as we may have to postpone driver > > > load to after end of dxe instead of just the connection. It seemed > > > that a driver binding > > type approach was a good approach for this. > > > > I am curious how the pcie root (root complex) initialization is done > > in async way? > > Does it use a timer callback to poll the initialization status every > > certain interval? > > > > [JB] That is correct, we use a timer when we expect sleeps or polling loops. > > > On the other hand, even you make PciHostBridge as a UEFI driver-model > > driver, you still require some code to initiate the > > "ConnectController()". How is that done? > > > > Comparing the two paths (today's = my proposal, new way = your patch), > > both require some code to explicitly call "ConnectController()". > > > > [JB] We have a sync point in BDS prior to the ConnectController call that is > made. I could put that and a dispatch call prior to EndOfDxe signal but was > hoping to not trigger any of the driver seen but not loaded debug messages > from the main dispatch loop if possible as that can be a useful message to > trigger something might be wrong. > > > > > > > On a less important implementation if the pieces that live under the > > > library are driver binding we have to reject any stop requests as > > > there is no driver linkage between the two layers. > > > > In x86, root complex (pcie root) is almost the root of all > > peripherals. I cannot see a value to Stop () the pcie root. > > If you check the PciBus implementation, it supports Stop() but the > > Stop() only succeeds when all upper layer drivers succeed to Stop(). > > (usually it's not the > > case.) And even PciBus.Stop() succeeds, the resource(MMIO/IO/BUS) > > allocation is not un-done. It's only the PciIo handles that are > > destroyed in software level. > > > > [JB] Yeah, not allowing stop to work on this isn't a big deal (and what we > currently have implemented) but it was something we noticed a while ago is > that we couldn't implement this even if we wanted to as there was no way to > stop the host bridge driver. > > > Thanks, > > Ray > > > > > > > > > > -Jeff > > > > > > > > > -Original Message- > > > From: Ni, Ray > > > Sent: Thursday, June 29, 2023 8:29 PM > > > To: Jeff Brasen ; devel@edk2.groups.io > > > Cc: Wang, Jian J ; Gao, Liming > > > ; Wu, Hao A > > > Subject: RE: [PATCH] MdeModulePkg/PciHostBridge: Add support for > > > driver binding > > > > > > External email: Use caution opening links or attachments > > > > > > > > > I failed to apply the patch in my local tree. > > > > > > It seems you invented a new EdkiiRootBridgeIo protocol and a certain > > > proprietary driver would produce this protocol instance. > > > Then the open source PciHostBridge driver starts on that. > > > > > > Then, why not implement your own PciHostBridgeLib and let it depends > > > on some "AllRootBridgeIoInformationIsReady" protocol. > > > So that the PciHostBridge driver could still call PciHostBridgeLib > > > and all your implementation in this patch can be in that lib. > > > > > > Thanks, > > > Ray > > > > > > > -Original Message- > > > > From: Jeff Brasen > > > > Sent: Friday, June 30, 2023 4:54 AM > > > > To: devel@edk2.groups.io > > > > Cc: Wang, Jian J ; Gao, Liming > > > > ; Wu, Hao A ; Ni, > > > > Ray ; Jeff Brasen > > > > Subject: [PATCH] MdeModulePkg/PciHostBridge: Add support for > > > > driver binding > > > > > > > > If the platform does not support
Re: [edk2-devel] [PATCH] MdeModulePkg/PciHostBridge: Add support for driver binding
> -Original Message- > From: Ni, Ray > Sent: Thursday, June 29, 2023 9:59 PM > To: Jeff Brasen ; devel@edk2.groups.io > Cc: Wang, Jian J ; Gao, Liming > ; Wu, Hao A > Subject: RE: [PATCH] MdeModulePkg/PciHostBridge: Add support for driver > binding > > External email: Use caution opening links or attachments > > > > -Original Message- > > From: Jeff Brasen > > Sent: Friday, June 30, 2023 11:21 AM > > To: Ni, Ray ; devel@edk2.groups.io > > Cc: Wang, Jian J ; Gao, Liming > > ; Wu, Hao A > > Subject: RE: [PATCH] MdeModulePkg/PciHostBridge: Add support for > > driver binding > > > > Not sure why the patch failed to apply I'll see if there is something > > wrong with my gitconfig tomorrow. The path you suggested below is > > exactly what our current implementation does. However, I am trying to > > make our pcie controller driver do async initialization so that using > > a depex is less ideal as we may have to postpone driver load to after > > end of dxe instead of just the connection. It seemed that a driver binding > type approach was a good approach for this. > > I am curious how the pcie root (root complex) initialization is done in async > way? > Does it use a timer callback to poll the initialization status every certain > interval? > [JB] That is correct, we use a timer when we expect sleeps or polling loops. > On the other hand, even you make PciHostBridge as a UEFI driver-model > driver, you still require some code to initiate the "ConnectController()". > How is > that done? > > Comparing the two paths (today's = my proposal, new way = your patch), > both require some code to explicitly call "ConnectController()". > [JB] We have a sync point in BDS prior to the ConnectController call that is made. I could put that and a dispatch call prior to EndOfDxe signal but was hoping to not trigger any of the driver seen but not loaded debug messages from the main dispatch loop if possible as that can be a useful message to trigger something might be wrong. > > > > On a less important implementation if the pieces that live under the > > library are driver binding we have to reject any stop requests as > > there is no driver linkage between the two layers. > > In x86, root complex (pcie root) is almost the root of all peripherals. I > cannot > see a value to Stop () the pcie root. > If you check the PciBus implementation, it supports Stop() but the Stop() only > succeeds when all upper layer drivers succeed to Stop(). (usually it's not the > case.) And even PciBus.Stop() succeeds, the resource(MMIO/IO/BUS) > allocation is not un-done. It's only the PciIo handles that are destroyed in > software level. > [JB] Yeah, not allowing stop to work on this isn't a big deal (and what we currently have implemented) but it was something we noticed a while ago is that we couldn't implement this even if we wanted to as there was no way to stop the host bridge driver. > Thanks, > Ray > > > > > > -Jeff > > > > > > -Original Message- > > From: Ni, Ray > > Sent: Thursday, June 29, 2023 8:29 PM > > To: Jeff Brasen ; devel@edk2.groups.io > > Cc: Wang, Jian J ; Gao, Liming > > ; Wu, Hao A > > Subject: RE: [PATCH] MdeModulePkg/PciHostBridge: Add support for > > driver binding > > > > External email: Use caution opening links or attachments > > > > > > I failed to apply the patch in my local tree. > > > > It seems you invented a new EdkiiRootBridgeIo protocol and a certain > > proprietary driver would produce this protocol instance. > > Then the open source PciHostBridge driver starts on that. > > > > Then, why not implement your own PciHostBridgeLib and let it depends > > on some "AllRootBridgeIoInformationIsReady" protocol. > > So that the PciHostBridge driver could still call PciHostBridgeLib and > > all your implementation in this patch can be in that lib. > > > > Thanks, > > Ray > > > > > -Original Message- > > > From: Jeff Brasen > > > Sent: Friday, June 30, 2023 4:54 AM > > > To: devel@edk2.groups.io > > > Cc: Wang, Jian J ; Gao, Liming > > > ; Wu, Hao A ; Ni, Ray > > > ; Jeff Brasen > > > Subject: [PATCH] MdeModulePkg/PciHostBridge: Add support for driver > > > binding > > > > > > If the platform does not support any PCIe devices using the library > > > > > > method allow devices to connect to host bridge via driver binding. > > > > > > > > > > > > Signed-off-by: Jeff Brasen > > > > > > --- > > > > > > .../Bus/Pci/PciHostBridgeDxe/PciHostBridge.c | 649 > > > ++ > > > > > > .../Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf | 1 + > > > > > > .../Bus/Pci/PciHostBridgeDxe/PciRootBridge.h | 13 + > > > > > > .../Pci/PciHostBridgeDxe/PciRootBridgeIo.c| 24 + > > > > > > MdeModulePkg/MdeModulePkg.dec | 4 + > > > > > > 5 files changed, 562 insertions(+), 129 deletions(-) > > > > > > > > > > > > diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c > > > b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c > >
Re: [edk2-devel] [PATCH] MdeModulePkg/PciHostBridge: Add support for driver binding
> -Original Message-
> From: Jeff Brasen
> Sent: Friday, June 30, 2023 11:21 AM
> To: Ni, Ray ; devel@edk2.groups.io
> Cc: Wang, Jian J ; Gao, Liming
> ; Wu, Hao A
> Subject: RE: [PATCH] MdeModulePkg/PciHostBridge: Add support for driver
> binding
>
> Not sure why the patch failed to apply I'll see if there is something wrong
> with my
> gitconfig tomorrow. The path you suggested below is exactly what our current
> implementation does. However, I am trying to make our pcie controller driver
> do
> async initialization so that using a depex is less ideal as we may have to
> postpone
> driver load to after end of dxe instead of just the connection. It seemed
> that a
> driver binding type approach was a good approach for this.
I am curious how the pcie root (root complex) initialization is done in async
way?
Does it use a timer callback to poll the initialization status every certain
interval?
On the other hand, even you make PciHostBridge as a UEFI driver-model driver,
you still
require some code to initiate the "ConnectController()". How is that done?
Comparing the two paths (today's = my proposal, new way = your patch), both
require
some code to explicitly call "ConnectController()".
>
> On a less important implementation if the pieces that live under the library
> are
> driver binding we have to reject any stop requests as there is no driver
> linkage
> between the two layers.
In x86, root complex (pcie root) is almost the root of all peripherals. I
cannot see a value to Stop () the pcie root.
If you check the PciBus implementation, it supports Stop() but the Stop() only
succeeds when all upper layer drivers
succeed to Stop(). (usually it's not the case.)
And even PciBus.Stop() succeeds, the resource(MMIO/IO/BUS) allocation is not
un-done. It's only the PciIo
handles that are destroyed in software level.
Thanks,
Ray
>
> -Jeff
>
>
> -Original Message-
> From: Ni, Ray
> Sent: Thursday, June 29, 2023 8:29 PM
> To: Jeff Brasen ; devel@edk2.groups.io
> Cc: Wang, Jian J ; Gao, Liming
> ; Wu, Hao A
> Subject: RE: [PATCH] MdeModulePkg/PciHostBridge: Add support for driver
> binding
>
> External email: Use caution opening links or attachments
>
>
> I failed to apply the patch in my local tree.
>
> It seems you invented a new EdkiiRootBridgeIo protocol and a certain
> proprietary
> driver would produce this protocol instance.
> Then the open source PciHostBridge driver starts on that.
>
> Then, why not implement your own PciHostBridgeLib and let it depends on some
> "AllRootBridgeIoInformationIsReady" protocol.
> So that the PciHostBridge driver could still call PciHostBridgeLib and all
> your
> implementation in this patch can be in that lib.
>
> Thanks,
> Ray
>
> > -Original Message-
> > From: Jeff Brasen
> > Sent: Friday, June 30, 2023 4:54 AM
> > To: devel@edk2.groups.io
> > Cc: Wang, Jian J ; Gao, Liming
> > ; Wu, Hao A ; Ni, Ray
> > ; Jeff Brasen
> > Subject: [PATCH] MdeModulePkg/PciHostBridge: Add support for driver
> > binding
> >
> > If the platform does not support any PCIe devices using the library
> >
> > method allow devices to connect to host bridge via driver binding.
> >
> >
> >
> > Signed-off-by: Jeff Brasen
> >
> > ---
> >
> > .../Bus/Pci/PciHostBridgeDxe/PciHostBridge.c | 649
> > ++
> >
> > .../Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf | 1 +
> >
> > .../Bus/Pci/PciHostBridgeDxe/PciRootBridge.h | 13 +
> >
> > .../Pci/PciHostBridgeDxe/PciRootBridgeIo.c| 24 +
> >
> > MdeModulePkg/MdeModulePkg.dec | 4 +
> >
> > 5 files changed, 562 insertions(+), 129 deletions(-)
> >
> >
> >
> > diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> > b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> >
> > index d573e532ba..506c6660ae 100644
> >
> > --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> >
> > +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> >
> > @@ -422,167 +422,320 @@ IoMmuProtocolCallback (
> >
> > }
> >
> >
> >
> > /**
> >
> > + PCI Root Bridge Memory setup.
> >
> >
> >
> > - Entry point of this driver.
> >
> > + @param RootBridgeRoot Bridge instance.
> >
> >
> >
> > - @param ImageHandle Image handle of this driver.
> >
> > - @param SystemTable Pointer to standard EFI system table.
> >
> > -
> >
> > - @retval EFI_SUCCESS Succeed.
> >
> > - @retval EFI_DEVICE_ERROR Fail to install PCI_ROOT_BRIDGE_IO protocol.
> >
> > + @retval EFI_SUCCESS Memory was setup correctly
> >
> > + @retval othersError in setup
> >
> >
> >
> > **/
> >
> > EFI_STATUS
> >
> > EFIAPI
> >
> > -InitializePciHostBridge (
> >
> > - IN EFI_HANDLEImageHandle,
> >
> > - IN EFI_SYSTEM_TABLE *SystemTable
> >
> > +PciRootBridgeMemorySetup (
> >
> > + IN PCI_ROOT_BRIDGE *RootBridge
> >
> >)
> >
> > {
> >
> >EFI_STATUSStatus;
> >
> > - PCI_HOST_BRIDGE_INSTANCE *HostBridge;
> >
Re: [edk2-devel] [PATCH] MdeModulePkg/PciHostBridge: Add support for driver binding
Not sure why the patch failed to apply I'll see if there is something wrong
with my gitconfig tomorrow. The path you suggested below is exactly what our
current implementation does. However, I am trying to make our pcie controller
driver do async initialization so that using a depex is less ideal as we may
have to postpone driver load to after end of dxe instead of just the
connection. It seemed that a driver binding type approach was a good approach
for this.
On a less important implementation if the pieces that live under the library
are driver binding we have to reject any stop requests as there is no driver
linkage between the two layers.
-Jeff
-Original Message-
From: Ni, Ray
Sent: Thursday, June 29, 2023 8:29 PM
To: Jeff Brasen ; devel@edk2.groups.io
Cc: Wang, Jian J ; Gao, Liming
; Wu, Hao A
Subject: RE: [PATCH] MdeModulePkg/PciHostBridge: Add support for driver binding
External email: Use caution opening links or attachments
I failed to apply the patch in my local tree.
It seems you invented a new EdkiiRootBridgeIo protocol and a certain
proprietary driver would produce this protocol instance.
Then the open source PciHostBridge driver starts on that.
Then, why not implement your own PciHostBridgeLib and let it depends on some
"AllRootBridgeIoInformationIsReady" protocol.
So that the PciHostBridge driver could still call PciHostBridgeLib and all your
implementation in this patch can be in that lib.
Thanks,
Ray
> -Original Message-
> From: Jeff Brasen
> Sent: Friday, June 30, 2023 4:54 AM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J ; Gao, Liming
> ; Wu, Hao A ; Ni, Ray
> ; Jeff Brasen
> Subject: [PATCH] MdeModulePkg/PciHostBridge: Add support for driver
> binding
>
> If the platform does not support any PCIe devices using the library
>
> method allow devices to connect to host bridge via driver binding.
>
>
>
> Signed-off-by: Jeff Brasen
>
> ---
>
> .../Bus/Pci/PciHostBridgeDxe/PciHostBridge.c | 649
> ++
>
> .../Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf | 1 +
>
> .../Bus/Pci/PciHostBridgeDxe/PciRootBridge.h | 13 +
>
> .../Pci/PciHostBridgeDxe/PciRootBridgeIo.c| 24 +
>
> MdeModulePkg/MdeModulePkg.dec | 4 +
>
> 5 files changed, 562 insertions(+), 129 deletions(-)
>
>
>
> diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
>
> index d573e532ba..506c6660ae 100644
>
> --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
>
> +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
>
> @@ -422,167 +422,320 @@ IoMmuProtocolCallback (
>
> }
>
>
>
> /**
>
> + PCI Root Bridge Memory setup.
>
>
>
> - Entry point of this driver.
>
> + @param RootBridgeRoot Bridge instance.
>
>
>
> - @param ImageHandle Image handle of this driver.
>
> - @param SystemTable Pointer to standard EFI system table.
>
> -
>
> - @retval EFI_SUCCESS Succeed.
>
> - @retval EFI_DEVICE_ERROR Fail to install PCI_ROOT_BRIDGE_IO protocol.
>
> + @retval EFI_SUCCESS Memory was setup correctly
>
> + @retval othersError in setup
>
>
>
> **/
>
> EFI_STATUS
>
> EFIAPI
>
> -InitializePciHostBridge (
>
> - IN EFI_HANDLEImageHandle,
>
> - IN EFI_SYSTEM_TABLE *SystemTable
>
> +PciRootBridgeMemorySetup (
>
> + IN PCI_ROOT_BRIDGE *RootBridge
>
>)
>
> {
>
>EFI_STATUSStatus;
>
> - PCI_HOST_BRIDGE_INSTANCE *HostBridge;
>
> - PCI_ROOT_BRIDGE_INSTANCE *RootBridge;
>
> - PCI_ROOT_BRIDGE *RootBridges;
>
> - UINTN RootBridgeCount;
>
> - UINTN Index;
>
> + UINT64HostAddress;
>
>PCI_ROOT_BRIDGE_APERTURE *MemApertures[4];
>
>UINTN MemApertureIndex;
>
> - BOOLEAN ResourceAssigned;
>
> - LIST_ENTRY*Link;
>
> - UINT64HostAddress;
>
>
>
> - RootBridges = PciHostBridgeGetRootBridges (&RootBridgeCount);
>
> - if ((RootBridges == NULL) || (RootBridgeCount == 0)) {
>
> -return EFI_UNSUPPORTED;
>
> - }
>
> -
>
> - Status = gBS->LocateProtocol (&gEfiCpuIo2ProtocolGuid, NULL, (VOID
> **)&mCpuIo);
>
> - ASSERT_EFI_ERROR (Status);
>
> -
>
> - //
>
> - // Most systems in the world including complex servers have only
> one Host Bridge.
>
> - //
>
> - HostBridge = AllocateZeroPool (sizeof (PCI_HOST_BRIDGE_INSTANCE));
>
> - ASSERT (HostBridge != NULL);
>
> -
>
> - HostBridge->Signature= PCI_HOST_BRIDGE_SIGNATURE;
>
> - HostBridge->CanRestarted = TRUE;
>
> - InitializeListHead (&HostBridge->RootBridges);
>
> - ResourceAssigned = FALSE;
>
> -
>
> - //
>
> - // Create Root Bridge Device Handle in this Host Bridge
>
> - //
>
> - for (Index = 0; Index < RootBridgeCount; Index++) {
>
> + if (RootBridge->Io.Base <= RootBridge->Io.Limit) {
>
> //
>
> -// Create Root Bridge Handle Instance
>
> +// Base and Limit
Re: [edk2-devel] [PATCH] MdeModulePkg/PciHostBridge: Add support for driver binding
I failed to apply the patch in my local tree.
It seems you invented a new EdkiiRootBridgeIo protocol and a certain
proprietary driver would produce this protocol instance.
Then the open source PciHostBridge driver starts on that.
Then, why not implement your own PciHostBridgeLib and let it depends on some
"AllRootBridgeIoInformationIsReady" protocol.
So that the PciHostBridge driver could still call PciHostBridgeLib and all your
implementation in this patch can be in that lib.
Thanks,
Ray
> -Original Message-
> From: Jeff Brasen
> Sent: Friday, June 30, 2023 4:54 AM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J ; Gao, Liming
> ; Wu, Hao A ; Ni, Ray
> ; Jeff Brasen
> Subject: [PATCH] MdeModulePkg/PciHostBridge: Add support for driver binding
>
> If the platform does not support any PCIe devices using the library
>
> method allow devices to connect to host bridge via driver binding.
>
>
>
> Signed-off-by: Jeff Brasen
>
> ---
>
> .../Bus/Pci/PciHostBridgeDxe/PciHostBridge.c | 649 ++
>
> .../Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf | 1 +
>
> .../Bus/Pci/PciHostBridgeDxe/PciRootBridge.h | 13 +
>
> .../Pci/PciHostBridgeDxe/PciRootBridgeIo.c| 24 +
>
> MdeModulePkg/MdeModulePkg.dec | 4 +
>
> 5 files changed, 562 insertions(+), 129 deletions(-)
>
>
>
> diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
>
> index d573e532ba..506c6660ae 100644
>
> --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
>
> +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
>
> @@ -422,167 +422,320 @@ IoMmuProtocolCallback (
>
> }
>
>
>
> /**
>
> + PCI Root Bridge Memory setup.
>
>
>
> - Entry point of this driver.
>
> + @param RootBridgeRoot Bridge instance.
>
>
>
> - @param ImageHandle Image handle of this driver.
>
> - @param SystemTable Pointer to standard EFI system table.
>
> -
>
> - @retval EFI_SUCCESS Succeed.
>
> - @retval EFI_DEVICE_ERROR Fail to install PCI_ROOT_BRIDGE_IO protocol.
>
> + @retval EFI_SUCCESS Memory was setup correctly
>
> + @retval othersError in setup
>
>
>
> **/
>
> EFI_STATUS
>
> EFIAPI
>
> -InitializePciHostBridge (
>
> - IN EFI_HANDLEImageHandle,
>
> - IN EFI_SYSTEM_TABLE *SystemTable
>
> +PciRootBridgeMemorySetup (
>
> + IN PCI_ROOT_BRIDGE *RootBridge
>
>)
>
> {
>
>EFI_STATUSStatus;
>
> - PCI_HOST_BRIDGE_INSTANCE *HostBridge;
>
> - PCI_ROOT_BRIDGE_INSTANCE *RootBridge;
>
> - PCI_ROOT_BRIDGE *RootBridges;
>
> - UINTN RootBridgeCount;
>
> - UINTN Index;
>
> + UINT64HostAddress;
>
>PCI_ROOT_BRIDGE_APERTURE *MemApertures[4];
>
>UINTN MemApertureIndex;
>
> - BOOLEAN ResourceAssigned;
>
> - LIST_ENTRY*Link;
>
> - UINT64HostAddress;
>
>
>
> - RootBridges = PciHostBridgeGetRootBridges (&RootBridgeCount);
>
> - if ((RootBridges == NULL) || (RootBridgeCount == 0)) {
>
> -return EFI_UNSUPPORTED;
>
> - }
>
> -
>
> - Status = gBS->LocateProtocol (&gEfiCpuIo2ProtocolGuid, NULL, (VOID
> **)&mCpuIo);
>
> - ASSERT_EFI_ERROR (Status);
>
> -
>
> - //
>
> - // Most systems in the world including complex servers have only one Host
> Bridge.
>
> - //
>
> - HostBridge = AllocateZeroPool (sizeof (PCI_HOST_BRIDGE_INSTANCE));
>
> - ASSERT (HostBridge != NULL);
>
> -
>
> - HostBridge->Signature= PCI_HOST_BRIDGE_SIGNATURE;
>
> - HostBridge->CanRestarted = TRUE;
>
> - InitializeListHead (&HostBridge->RootBridges);
>
> - ResourceAssigned = FALSE;
>
> -
>
> - //
>
> - // Create Root Bridge Device Handle in this Host Bridge
>
> - //
>
> - for (Index = 0; Index < RootBridgeCount; Index++) {
>
> + if (RootBridge->Io.Base <= RootBridge->Io.Limit) {
>
> //
>
> -// Create Root Bridge Handle Instance
>
> +// Base and Limit in PCI_ROOT_BRIDGE_APERTURE are device address.
>
> +// For GCD resource manipulation, we need to use host address.
>
> //
>
> -RootBridge = CreateRootBridge (&RootBridges[Index]);
>
> -ASSERT (RootBridge != NULL);
>
> -if (RootBridge == NULL) {
>
> - continue;
>
> +HostAddress = TO_HOST_ADDRESS (
>
> +RootBridge->Io.Base,
>
> +RootBridge->Io.Translation
>
> +);
>
> +
>
> +Status = AddIoSpace (
>
> + HostAddress,
>
> + RootBridge->Io.Limit - RootBridge->Io.Base + 1
>
> + );
>
> +ASSERT_EFI_ERROR (Status);
>
> +if (EFI_ERROR (Status)) {
>
> + return Status;
>
> }
>
>
>
> -//
>
> -// Make sure all root bridges share the same ResourceAssigned value.
>
> -//
>
> -if (Index == 0) {
>
> -
