I have a software driver that needs information about BAR addresses of a PCI device (a different driver). The PCI device has an interface, which I have no problem accessing from my driver, and in that interface a device handle is provided. I tried to fully replicate the device context structure of the PCI device and then use an equivalent of GetDeviceContext macro to gain access to the device context, where the PCI device driver keeps information on BAR addresses. When I call this macro and pass the device handle, I get a null pointer - so, I hit the wall here.
The reason I’m doing it this roundabout way is that I do have the full source code for this PCI driver, but I cannot modify it to extend the interface with data that I need.
Is there a way to access device context info of another driver, or WDF somehow restricts access to it, even when one has the full layout of device context structure?
You’re thinking about it wrong. You want to export the information (not the data structures) from your PCI driver to your software driver. Have your software driver “talk” to your PCI driver (using any one of a variety of techniques…send an IRP with an internal IOCTL, use a bus interfaces etc) and have the PCI driver provide the info that’s needed.
Don’t reach around into some other driver’s data structures. That’s ugly.
Peter
Apparently the op cannot modify the PCI driver, despite having the source code. The only way to legitimately get at the config space is to add a filter driver on top of the pci driver and have it provide the missing information to this ‘software driver’. Note that the filter driver and the ‘software driver’ could be the same binary.
The first question is what are you going to do with the BAR addresses? With the second being do you really want the BAR or the mapped hardware. Until you explain some more about what you are doing giving an approach is going to be challenging.
Apparently the op cannot modify the PCI driver
Sorry, yes. He DID say that, didn’t he.
What Mr. Roddy said, OP… Filter driver.
Peter
Filter driver sounds like a good idea, but… how will the filter driver get to the information I need? I understand that the filter driver will now be receiving all the requests directed at the PCI driver, but how exactly will I get to BAR info? Can the filter driver access the underlying PDO and, if so, how?
@Don_Burn : the actual hardware controlled by the PCI driver is a multi-function card. I have already used, in another driver, information about BAR2 address to access the physical hardware registers. This was possible because the PCI driver was exposing BAR2 address range via device interface. But now I need to access the hardware behind BAR1, and this is not exposed via existing device interface (which I cannot change). That’s why I’m looking for other ways to get to that information, without modifying the existing PCI driver.
As a filter driver, you would receive the IRP_MN_START_DEVICE request in which the resources are sent to the driver. Alternatively, you could make an IRP_MN_READ_CONFIG request to read the configuration space directly.
Could the reason the PCI driver is not exposing BAR1 is that it is accessing BAR1 itself? If so you have no way to control whether or not the PCI driver is accessing the device when you try to, that way leads to chaos or crashes.
Thank you @Tim_Roberts , I’ll try that. @Don_Burn , the existing PCI driver is not using the hardware behind BAR1, it’s not hiding it deliberately. I’m trying to gain access to that hardware without disturbing the existing driver.
Doing this the right way would be for the filter driver to also be a bus driver and expose ‘BAR1’ as a new child PDO device. You can also just have a private interface of some sort to pass the BAR1 resource to your ‘software driver’, but you may have to participate in power management and pnp state changes that are much simpler to get right if you just let KMDF do its thing.