Re: One question about the useage of pci_dev->resource[]

[Richard Yang <weiyang@linux.vnet.ibm.com>]

On Tue, Jun 26, 2012 at 06:16:08AM -0600, Bjorn Helgaas wrote:
>On Mon, Jun 25, 2012 at 7:57 PM, Richard Yang
><weiyang@linux.vnet.ibm.com> wrote:
>> On Wed, Jun 20, 2012 at 04:45:15PM +0800, Richard Yang wrote:
>>>All,
>>>
>>>I want to confirm something for the pci_dev->resource[].
>>>
>>>As in the definition in the pci.h, this resource array is divided into
>>>several parts.
>>>    0-5  for standard PCI resources
>>>    6    for ROM resource
>>>    7-10 for bridge resource( if no iov )
>>>
>>>
>>>1. For P2P bridge, 0-5 is left empty?
>>>2. If so, in code pci_setup_device(), I think it set the wrong resource.
>>>   It call pci_read_bases(dev, 2, PCI_ROM_ADDRESS1), for a p2p bridge.
>>>   And in pci_read_bases(), BAR information is retrieved and set to
>>>   pci_dev->resource[0|1].
>>>3. If pci_setup_device() just set first two resource, the child bus will
>>>   point to empty resource.
>>>   In pci_alloc_child_bus(), child->resource[0-3] will be point to
>>>   bridge->resource[7-10], which is not set in pci_setup_device().
>>>4. Another question is, is there any convention for pci_bus->resource[].
>>>   [0] for io, [1] for mem, [2] for prefetch?
>> All,
>>
>> I go through the code again and find pci_dev->resource[7-10] is used for
>> io/mem base/limit, which is used by the bridge to determine whether it
>> will forward one pci transaction.
>>
>> So pci_dev->[0-1] is used by the bridge's driver?
>
>Per the PCI-to-PCI Bridge spec v1.2, config space for type 1 devices
>(bridges) has two BARs in addition to the I/O, mem, and prefetchable
>mem windows.  These two BARs are optional and can be used for
>device-specific configuration of the bridge itself.  This is unrelated
>to forwarding transactions.  See sec 3.2.5.1.
>
>The bridge consumes the address space described by the windows and
>forwards it to its secondary interface.  It also consumes the address
>space described by those BARs, without forwarding it.  Therefore, we
>have to read the BARs to make sure we don't allocate that space to
>anything else.
>
>There *could* be device-specific bridge drivers that actually do
>something with those BARs, but I'm not aware of any in Linux.
Thanks for your confirmation. :-)
>
>Bjorn

-- 
Richard Yang
Help you, Help me