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: 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
> -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
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
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
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
