Peter Stuge wrote:
On Wed, Aug 15, 2007 at 03:21:29PM +0700, Darmawan Salihun wrote:
Yup. Are you saying it is simply not possible to access PCI config space of a device from a device driver unless the driver is in fact part of the driver stack associated with that device?
Yes.
Yeah, this is an already known issue from the beginning ;-). Technically, we don't have the PDO of the southbridge chip, therefore we cannot access it in anyway as documented by Micro$oft.
What is required to get into the southbridge driver stack?
I'm not too sure. I think a "PCI bus filter driver", but that would be an overkill at the moment. The other problem is it's not well documented (maybe not documented at all :-/). I hardly found information about such a thing. Even, experts in Windows driver development says so.
From the little reading I've done the last day or two it seems that
a driver would not have to do very much once in the stack. Is it really not feasible? It would definately be the cleanest way.
Yes, this is the cleanest way. However, we have to "attach" our driver entry point functions, including "AddDevice" function upon the first time the southbridge driver is installed. More like we make a driver for Intel, NVidia, AMD or Via chipset driver. The PnP manager will try to find the driver for the corresponding device the first time it's found after Windows installation and it seems once it has the driver we wouldn't be able to add our own "hook" into the driver stack. Unless we make the thing called "PCI bus filter driver" or other "Bus filter driver" as needed. But, the problem goes back to the beginning, it's not even documented. I think Microsoft has a reason to make it not documented.
Regards, Darmawan