1. Edk2 | Discuss
  2. Topics

Question about NonDiscoverablePciDeviceDxe

Jeff Brasen
 

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

Laszlo Ersek
 

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





Jeff Brasen
 

-----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,
Jeff


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








Laszlo Ersek
 

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








Jeff Brasen
 

-----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.
[JMB] That works for me, just wasn't sure if there was a desire to keep the stuff in this driver to generic standard supported stuff.

Thanks,
Jeff

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








1 - 5 of 5