From: Pavel A. on
"RossettoeCioccolato" <rossetoecioccolato(a)newsgroup.nospam> wrote in message
news:uzGX0JmmKHA.3792(a)TK2MSFTNGP02.phx.gbl...
> Pavel,
>
>> then send IRP_MN_READ_CONFIG to it. <
>
> I think that the problem is that the OP needs to do this from within an
> ISR (i.e. at elevated IRQL).
>
> Regards,
>
> Rossetoecioccolato.

Why ISR? This is not mentioned in the orig. question.
Even if so, the problem is how to get the device object of the bridge.
Then you can either use IRP_MN_READ_CONFIG or IRP_MN_QUERY_INTERFACE.

Regards,
--pa





From: Patrick on
Thanks. I will give that a try.

"Pavel A." wrote:

> Using SetupDi, you can find the device name of your brigde.
> but opening it in usermode most probably won't work.
> Maybe it is possible to open it in kernel mode, by something like
> IoGetDeviceObjectPointer,
> then send IRP_MN_READ_CONFIG to it.
> ( I haven't tried the latter part though.)
>
> Good luck.
> -- pa
>
> "Patrick" <Patrick(a)discussions.microsoft.com> wrote in message
> news:164AA05C-D997-4245-8BE4-E4B9DEF8090B(a)microsoft.com...
> > Hi all,
> >
> > I've a system which containing several PLX bridges. I need access to a
> > particular GPIO register which exists in the extended PCI Config Space.
> > Previously we were using HalGetBusData/SetBusData to toggle the GPIO, but
> > these calls are now invalid in Vista.
> >
> > The driver for the PLX bridges are the default pci.sys (from
> > Microsoft).
> >
> > Is there a method to do this ? Some of the newer calls requires the
> > PDO or DO, and these calls only allow me to read/write the PCI Config
> > space
> > of my own device. What I need is the ability to read/write the PCI Config
> > Space of another device. For Vista, how can a driver do (1) scan all
> > devices in the pci bridge (2) select a device, and go modify the PCI
> > Config
> > Space ?
> >
> > At this point, all I can get is the bus/device/function id of the PLX
> > bridge that I need to modify the GPIO, but I am not really sure how I can
> > get
> > access to that device's config space to make the change. Any advice will
> > be
> > much appreciated.
> >
> >
From: Patrick on
Thanks for info. I will give it a try

"RossettoeCioccolato" wrote:

> Patrick,
>
> > I am not sure whether I can use that call to peek at another device's
> > config space
> > (in my > case the PLX bridge). <
>
> If you query the interface from the correct device object it will work. I
> haven't tried it specifically in an ISR though, so I don't know about that.
> You will have to try it and see if it works.
>
> Regards,
>
> Rossetoecioccolato.
>
>
> .
>
From: Pavel A. on
"Don Burn" <burn(a)stopspam.windrvr.com> wrote in message
news:uUbwW0smKHA.6096(a)TK2MSFTNGP02.phx.gbl...
> Yes it does crash, you have a 2 step process with no access to the lock,
> how do you prevent your code from stopping the actions of the kernel in
> the middle. I.E. they have set the address register but not accessed the
> data register, then you blow away the address register.
>
> --
> Don Burn (MVP, Windows DKD)
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply

AFAIK at least on some current Intel platforms, PCI config
space of bridges (and maybe of all PCI(e) devices)
is permanently mapped to memory. So pci.sys does not
use the legacy i/o interface.
This may explain why Alberto is so lucky ;)

Regards,
-- pa

> "alberto" <amoreira(a)ieee.org> wrote in message
> news:7daea67a-c15d-4e01-9b75-5593dd71da77(a)k17g2000yqh.googlegroups.com...
>
> Do it right, and it doesn't crash. In fact, the closest you are to the
> hardware, the less things can go wrong, and if I have to decide
> between trusting the hardware or trusting the OS, I'll trust the
> hardware 100% of the time. All it takes is to know your hardware
> well.
>
> I do direct bus access a couple of times in my own driver - what do
> you know, to fiddle with the onboard PCI-X to PCIe bridge - and yet
> the driver is now at a stage that it runs in stress conditions 24/7
> for weeks uninterrupted.
>
> But what is it so important in a PCI config register that it requires
> access at interrupt time ? For most cases I can think of, a shadow
> will do fine.
>
> Alberto.
>
>
> On Jan 20, 1:45 pm, "Don Burn" <b...(a)stopspam.windrvr.com> wrote:
>> It is a wonderful way to crash a system, this is one of the worst
>> suggestions that could be made.
>>
>> --
>> Don Burn (MVP, Windows DKD)
>> Windows Filesystem and Driver Consulting
>> Website:http://www.windrvr.com
>> Blog:http://msmvps.com/blogs/WinDrvr
>> Remove StopSpam to reply
>>
>> "alberto" <amore...(a)ieee.org> wrote in message
>>
>> news:a03b6446-0abd-4dad-a9b8-ac18effa20ae(a)p8g2000yqb.googlegroups.com...
>>
>> Have you tried to use CF8/CFC ? I know this is a big no-no in
>> Windowsland, but sometimes there isn't any better alternative.
>>
>> Alberto.
>>
>> On Jan 19, 6:03 pm, Patrick <Patr...(a)discussions.microsoft.com> wrote:
>>
>>
>>
>>
>>
>> > Hi all,
>>
>> > I've a system which containing several PLX bridges. I need access to a
>> > particular GPIO register which exists in the extended PCI Config Space.
>> > Previously we were using HalGetBusData/SetBusData to toggle the GPIO,
>> > but
>> > these calls are now invalid in Vista.
>>
>> > The driver for the PLX bridges are the default pci.sys (from
>> > Microsoft).
>>
>> > Is there a method to do this ? Some of the newer calls requires the
>> > PDO or DO, and these calls only allow me to read/write the PCI Config
>> > space
>> > of my own device. What I need is the ability to read/write the PCI
>> > Config
>> > Space of another device. For Vista, how can a driver do (1) scan all
>> > devices in the pci bridge (2) select a device, and go modify the PCI
>> > Config
>> > Space ?
>>
>> > At this point, all I can get is the bus/device/function id of the PLX
>> > bridge that I need to modify the GPIO, but I am not really sure how I
>> > can
>> > get
>> > access to that device's config space to make the change. Any advice
>> > will
>> > be
>> > much appreciated.
>>
>
From: Don Burn on
I believe you are correct about the platforms, but Alberto specifically
called out using the legacy interface and that will nail a system sometime.


--
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply


"Pavel A." <pavel_a(a)12fastmail34.fm> wrote in message
news:eeCNv9smKHA.1708(a)TK2MSFTNGP05.phx.gbl...
> "Don Burn" <burn(a)stopspam.windrvr.com> wrote in message
> news:uUbwW0smKHA.6096(a)TK2MSFTNGP02.phx.gbl...
>> Yes it does crash, you have a 2 step process with no access to the lock,
>> how do you prevent your code from stopping the actions of the kernel in
>> the middle. I.E. they have set the address register but not accessed
>> the data register, then you blow away the address register.
>>
>> --
>> Don Burn (MVP, Windows DKD)
>> Windows Filesystem and Driver Consulting
>> Website: http://www.windrvr.com
>> Blog: http://msmvps.com/blogs/WinDrvr
>> Remove StopSpam to reply
>
> AFAIK at least on some current Intel platforms, PCI config
> space of bridges (and maybe of all PCI(e) devices)
> is permanently mapped to memory. So pci.sys does not
> use the legacy i/o interface.
> This may explain why Alberto is so lucky ;)
>
> Regards,
> -- pa
>
>> "alberto" <amoreira(a)ieee.org> wrote in message
>> news:7daea67a-c15d-4e01-9b75-5593dd71da77(a)k17g2000yqh.googlegroups.com...
>>
>> Do it right, and it doesn't crash. In fact, the closest you are to the
>> hardware, the less things can go wrong, and if I have to decide
>> between trusting the hardware or trusting the OS, I'll trust the
>> hardware 100% of the time. All it takes is to know your hardware
>> well.
>>
>> I do direct bus access a couple of times in my own driver - what do
>> you know, to fiddle with the onboard PCI-X to PCIe bridge - and yet
>> the driver is now at a stage that it runs in stress conditions 24/7
>> for weeks uninterrupted.
>>
>> But what is it so important in a PCI config register that it requires
>> access at interrupt time ? For most cases I can think of, a shadow
>> will do fine.
>>
>> Alberto.
>>
>>
>> On Jan 20, 1:45 pm, "Don Burn" <b...(a)stopspam.windrvr.com> wrote:
>>> It is a wonderful way to crash a system, this is one of the worst
>>> suggestions that could be made.
>>>
>>> --
>>> Don Burn (MVP, Windows DKD)
>>> Windows Filesystem and Driver Consulting
>>> Website:http://www.windrvr.com
>>> Blog:http://msmvps.com/blogs/WinDrvr
>>> Remove StopSpam to reply
>>>
>>> "alberto" <amore...(a)ieee.org> wrote in message
>>>
>>> news:a03b6446-0abd-4dad-a9b8-ac18effa20ae(a)p8g2000yqb.googlegroups.com...
>>>
>>> Have you tried to use CF8/CFC ? I know this is a big no-no in
>>> Windowsland, but sometimes there isn't any better alternative.
>>>
>>> Alberto.
>>>
>>> On Jan 19, 6:03 pm, Patrick <Patr...(a)discussions.microsoft.com> wrote:
>>>
>>>
>>>
>>>
>>>
>>> > Hi all,
>>>
>>> > I've a system which containing several PLX bridges. I need access to a
>>> > particular GPIO register which exists in the extended PCI Config
>>> > Space.
>>> > Previously we were using HalGetBusData/SetBusData to toggle the GPIO,
>>> > but
>>> > these calls are now invalid in Vista.
>>>
>>> > The driver for the PLX bridges are the default pci.sys (from
>>> > Microsoft).
>>>
>>> > Is there a method to do this ? Some of the newer calls requires the
>>> > PDO or DO, and these calls only allow me to read/write the PCI Config
>>> > space
>>> > of my own device. What I need is the ability to read/write the PCI
>>> > Config
>>> > Space of another device. For Vista, how can a driver do (1) scan all
>>> > devices in the pci bridge (2) select a device, and go modify the PCI
>>> > Config
>>> > Space ?
>>>
>>> > At this point, all I can get is the bus/device/function id of the PLX
>>> > bridge that I need to modify the GPIO, but I am not really sure how I
>>> > can
>>> > get
>>> > access to that device's config space to make the change. Any advice
>>> > will
>>> > be
>>> > much appreciated.
>>>
>>
>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 4794 (20100121) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4794 (20100121) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com