On Tue, Aug 14, 2007 at 12:14:22PM -0500, Roman Kononov wrote: > On 08/14/2007 07:56 AM, Peter Stuge wrote: > > Roman did make a good point about IRQL but that does not eliminate > > the problem, we will still be changing hardware state underneath the > > OS and that is ALWAYS a bad idea. > > The CF8/CFC sequence can preserve CF8 port value. What other > hardware state would be changed?
The bits that are changed in the device config space. > > http://www.hollistech.com/Resources/Misc%20articles/getbusdata.htm > > http://www.freelists.org/archives/wdmaudiodev/03-2004/msg00010.html > > BTW, here is the "official" example: > http://support.microsoft.com/kb/253232 > > Unfortunately, AFAIK, this approach does not work for cases like > yours. It requires the "DeviceObject", which MUST be associated > with a PARTICULAR PCI function. Right, I assumed that it would be possible to get that through some sequence of system calls that look at the PCI bus. > Q: In the above links, among HtsReadWriteConfig() and > WritePCIConfigSpace() argument lists, which arguments are bus > number and device number? > A: They are inside PDEVICE_OBJECT, which structure is "opaque". 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? I suppose Microsoft considers that a feature? It would certainly explain why there aren't already several applications for reprogramming flash on Windows. But, on the other hand, there are a few applications that _do_. So how do they do it? > This means that the DPC method might be quite expensive. If this is the only way to access PCI config space for unrelated devices then I guess it's the best we can do - unless we can make ourselves be part of the driver stack for the southbridge? Or maybe there is in fact a userspace API for PCI config access? I am by no means a Windows API or WDM expert, then I'd already written the code. :p That world is a pretty strange place. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios