-----Original Message-----
From: Laszlo Ersek <lersek@...>
Sent: Thursday, October 8, 2020 7:26 AM
To: Jeff Brasen <jbrasen@...>; discuss@edk2.groups.io
Subject: Re: [edk2-discuss] Question about NonDiscoverablePciDeviceDxe

External email: Use caution opening links or attachments


On 10/07/20 17:53, Jeff Brasen wrote:

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of
Laszlo Ersek
Sent: Wednesday, October 7, 2020 8:01 AM
To: discuss@edk2.groups.io; Jeff Brasen <jbrasen@...>
Subject: Re: [edk2-discuss] Question about
NonDiscoverablePciDeviceDxe

External email: Use caution opening links or attachments


On 10/06/20 23:52, Jeff Brasen wrote:

We have a use case where we would want to expose PciIO protocols for
a

device that doesn't match any of the guids that it supports.

What do you mean by "guids"? Did you mean "vendor id / device id"
perhaps?

[JMB] Sorry, should have been clearer

I was referring to the variable STATIC CONST EFI_GUID * CONST
SupportedNonDiscoverableDevices[] = {

That both guards the supported function in the binding protocol as well as

the selection of the right values in InitializePciIoProtocol.

The vendor/device ids are one of the things we will need to set based on

any extension to this.

Thanks for the explanation, I got it now.

Could you simply contribute the code to edk2 that you need in
MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe?

If you add a new GUID and new branches in the driver that depend on that
GUID, that won't bother other consumers of the driver.

You mention "edk2-platforms area" below, so I assume you don't mind
open-sourcing the logic itself. My suggestion would be to simply extend
NonDiscoverablePciDeviceDxe right where it lives, in edk2.

Thanks
Laszlo

Before we go and implement support for this wanted to get a feeling
from

the community on what to do.

1. Fork NonDiscoverablePciDeviceDxe to our edk2-platforms area
for

support for this (Doesn't seem ideal)

2. Add support for extending this
* Add a protocol that this driver consumes for overrides
* Add a library initializer that registers overrides in both the

supported

function and the configuration space setup code

Any thoughts?

Thanks,
Jeff

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of
Laszlo Ersek
Sent: Wednesday, October 7, 2020 8:01 AM
To: discuss@edk2.groups.io; Jeff Brasen <jbrasen@...>
Subject: Re: [edk2-discuss] Question about NonDiscoverablePciDeviceDxe

External email: Use caution opening links or attachments


On 10/06/20 23:52, Jeff Brasen wrote:

We have a use case where we would want to expose PciIO protocols for a

device that doesn't match any of the guids that it supports.

What do you mean by "guids"? Did you mean "vendor id / device id"
perhaps?

Thanks
Laszlo

Before we go and implement support for this wanted to get a feeling from

the community on what to do.

1. Fork NonDiscoverablePciDeviceDxe to our edk2-platforms area for

support for this (Doesn't seem ideal)

2. Add support for extending this
* Add a protocol that this driver consumes for overrides
* Add a library initializer that registers overrides in both the supported

function and the configuration space setup code

Any thoughts?

Thanks,
Jeff