pci bridge device stack

Hi ,
Following is the devstack of a pci bridge
lkd> !devstack 0x89f607e0
!DevObj !DrvObj !DevExt ObjectName
89f64e58 \Driver\PCI 89f64f10
89f62e00 \Driver\ACPI 89f84298 0000004d

89f607e0 \Driver\PCI 89f60898 NTPNP_PCI0013
89f64e58 is the FDO for pci bridge , my question is why there is a
ACPI object under
the bridge . It’s the lowerfilter(class level but I can’t find one) ?
Or it is added by the pci
bus driver ? I’ve found all bridge type device have the similar stack
. Another example:
lkd> !devstack 0x89eef9e8
!DevObj !DrvObj !DevExt ObjectName
89f2a838 \Driver\isapnp 89f2a8f0
89f28358 \Driver\ACPI 89fa6900 00000048
89eef9e8 \Driver\PCI 89eefaa0 NTPNP_PCI0014
the device is a LPC controller . thanks in advance

acpi is a bus filter driver, it adds itself to a lot of stacks manually at runtime as the stacks are being built. is this causing a problem?

d

not by the normal PnP filter mechanism , right ?

2011/1/11 :
> it adds itself to a lot of stacks manually at runtime

bus filter drivers do not get loaded into the stack using the registry for the device (device filters) or by the class (class filters). it manually adds itself into the stack. so if that is what you mean by not the normal PnP filter mechanism, then yes, it is not by the normal PnP filter mechanism. Why does it matter? bus filter drivers are not documented nor publicly supported

d

got it . thanks.

2011/1/11 :
> bus filter drivers do not get loaded into the stack using the registry for the device (device filters) or by the class (class filters). it manually adds itself into the stack. so if that is what you mean by not the normal PnP filter mechanism, then yes, it is not by the normal PnP filter mechanism. Why does it matter? bus filter drivers are not documented nor publicly supported
>
> d
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

Doron answered the “how” part of your question. I’ll answer the “why” part.

ACPI.sys attaches itself to any stack for which there is a corresponding
device object in the ACPI namespace supplied by the BIOS. (See
http://acpi.info for details.) This allows the ACPI driver to participate
in handling any PnP or power IRPs flowing through that stack. If you read
the ACPI spec, many of the objects in the ACPI namespace are there to add
information or functionality used in PnP/power. In fact, there’s almost a
1:1 correspondence between ACPI objects and WDM PnP/power IRPs.

Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group

This post implies no warranties and confers no rights.


“yushang” wrote in message news:xxxxx@ntdev…

Hi ,
Following is the devstack of a pci bridge
lkd> !devstack 0x89f607e0
!DevObj !DrvObj !DevExt ObjectName
89f64e58 \Driver\PCI 89f64f10
89f62e00 \Driver\ACPI 89f84298 0000004d

89f607e0 \Driver\PCI 89f60898 NTPNP_PCI0013
89f64e58 is the FDO for pci bridge , my question is why there is a
ACPI object under
the bridge . It’s the lowerfilter(class level but I can’t find one) ?
Or it is added by the pci
bus driver ? I’ve found all bridge type device have the similar stack
. Another example:
lkd> !devstack 0x89eef9e8
!DevObj !DrvObj !DevExt ObjectName
89f2a838 \Driver\isapnp 89f2a8f0
89f28358 \Driver\ACPI 89fa6900 00000048
89eef9e8 \Driver\PCI 89eefaa0 NTPNP_PCI0014
the device is a LPC controller . thanks in advance

thanks . I’ll check it for details.

2011/1/12 Jake Oshins :
> Doron answered the “how” part of your question. I’ll answer the “why” part.
>
> ACPI.sys attaches itself to any stack for which there is a corresponding
> device object in the ACPI namespace supplied by the BIOS. (See
> http://acpi.info for details.) This allows the ACPI driver to participate
> in handling any PnP or power IRPs flowing through that stack. If you read
> the ACPI spec, many of the objects in the ACPI namespace are there to add
> information or functionality used in PnP/power. In fact, there’s almost a
> 1:1 correspondence between ACPI objects and WDM PnP/power IRPs.
>
>
> Jake Oshins
> Hyper-V I/O Architect
> Windows Kernel Group
>
> This post implies no warranties and confers no rights.
>
> --------------------------------------------------------------
> “yushang” wrote in message news:xxxxx@ntdev…
>
> Hi ,
> Following is the devstack of a pci bridge
> lkd> !devstack 0x89f607e0
> !DevObj !DrvObj !DevExt ObjectName
> 89f64e58 \Driver\PCI 89f64f10
> 89f62e00 \Driver\ACPI 89f84298 0000004d
>>
>> 89f607e0 \Driver\PCI 89f60898 NTPNP_PCI0013
>
> 89f64e58 is the FDO for pci bridge , my question is why there is a
> ACPI object under
> the bridge . It’s the lowerfilter(class level but I can’t find one) ?
> Or it is added by the pci
> bus driver ? I’ve found all bridge type device have the similar stack
> . Another example:
> lkd> !devstack 0x89eef9e8
> !DevObj !DrvObj !DevExt ObjectName
> 89f2a838 \Driver\isapnp 89f2a8f0
> 89f28358 \Driver\ACPI 89fa6900 00000048
>>
>> 89eef9e8 \Driver\PCI 89eefaa0 NTPNP_PCI0014
>
> the device is a LPC controller . thanks in advance
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>