[lkml]   [2012]   [May]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH -v11 04/30] PCI: Add busn_res into struct pci_bus.
    On Mon, Apr 30, 2012 at 6:32 PM, Yinghai Lu <> wrote:
    > On Mon, Apr 30, 2012 at 4:25 PM, Bjorn Helgaas <> wrote:
    >>> --- a/include/linux/pci.h
    >>> +++ b/include/linux/pci.h
    >>> @@ -419,6 +419,7 @@ struct pci_bus {
    >>>        struct list_head slots;         /* list of slots on this bus */
    >>>        struct resource *resource[PCI_BRIDGE_RESOURCE_NUM];
    >>>        struct list_head resources;     /* address space routed to this bus */
    >>> +       struct resource busn_res;       /* track registered bus num range */
    >>>        struct pci_ops  *ops;           /* configuration access functions */
    >>>        void            *sysdata;       /* hook for sys-specific extension */
    >> struct pci_bus already includes "secondary" and "subordinate".    This
    >> new "busn_res" looks like it will contain the same information.  Why
    >> do we need both?
    > In some case the could be different.
    > for root bus from _CRS, busn_res could bigger than subordinate,
    > because scan_childbus will update subordinate.

    For a bus below a P2P bridge, I think it's always the case that the
    bridge's Subordinate Bus Number in config space == bus->subordinate ==
    bus->busn_res.end (correct me if I'm wrong). I don't like the
    redundancy in this case.

    For a root bus where you set bus->busn_res from _CRS and
    bus->subordinate = pci_scan_child_bus(), bus->busn_res.end will
    generally be different from bus->subordinate, but there's no point in
    keeping track of bus->subordinate.

    The reason we care about secondary and subordinate is so we can
    allocate bus numbers when enumerating devices behind a bridge. The
    only thing we need for that is the aperture of the upstream bridge and
    the apertures of any peer bridges on the same bus. Let's say we have

    pci 00:00.0 bridge to [bus a-b]
    pci a:01.0 bridge to [bus c-d] (already enumerated)
    pci a:02.0 bridge to [bus e-f] (already enumerated)
    pci a:03.0 bridge to [bus x-y] (enumerating now)

    We know [c-d] is contained in [a-b]; [e-f] is contained in [a-b]; a <
    c; and a < e. To enumerate behind a:03.0, we need to assign x & y
    such that a < x; [x-y] is contained in [a-b]; and [x-y] does not
    overlap [c-d] or [e-f]. The value from pci_scan_child_bus() is
    probably useful for setting y, but we don't have to save it in the
    struct pci_bus for that.

    > and also we have one resource to insert it into the resource tree, so
    > later could probe/allocate bus num range.

    Sorry, I didn't understand this.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2012-05-01 06:42    [W:0.025 / U:34.000 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site