Re: [PATCH v0 00/13] PCI: Static Enumeration

Re: [PATCH v0 00/13] PCI: Static Enumeration

[Tang, Jason (ES)]

> From: linux-pci-owner@vger.kernel.org [mailto:linux-pci-
> owner@vger.kernel.org] On Behalf Of Bruno Santos
> Sent: Tuesday, January 19, 2016 13:31
> To: linux-pci@vger.kernel.org
> Subject: Re: [PATCH v0 00/13] PCI: Static Enumeration
> 
> 
> 
> Hello Jason,
> Where I can get the source code and examples to test in RHEL 6.5?

The source code to my enumeration changes can be found in the mailing list archives. The original patches are at http://www.spinics.net/lists/linux-pci/msg41689.html, the second (hotplug-based) version is at http://www.spinics.net/lists/linux-pci/msg44721.html.

You will need to recompile your kernel with the patches applied. However, RHEL 6.5 is based upon the 2.6.32 kernel, and my work is based upon 4.0+ kernels. It is unlikely that my changes will work on such an old kernel version.

Re: [PATCH v0 00/13] PCI: Static Enumeration

[Tang, Jason (ES)]

PiBGcm9tOiBCcnVubyBTYW50b3MgW21haWx0bzpic2FudG9zQGlwZm4uaXN0LnV0bC5wdF0gDQo+
IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDIxLCAyMDE2IDEwOjM2DQo+IFRvOiBUYW5nLCBKYXNv
biAoRVMpDQo+IENjOiBsaW51eC1wY2lAdmdlci5rZXJuZWwub3JnDQo+IFN1YmplY3Q6IFJlOiBb
UEFUQ0ggdjAgMDAvMTNdIFBDSTogU3RhdGljIEVudW1lcmF0aW9uDQo+DQo+IEkndmUgaW5zdGFs
bGVkIHRoZSBGZWRvcmEgMjMgd2l0aCBrZXJuZWwgNC4zIHRvIHRlc3QgdGhpcyBwYXRjaC4gSSd2
ZQ0KPiBmb3VuZCB0aGUgbWVzc2FnZXMgYWJvdXQgdGhlIHBhdGNoIGJ1dCBpcyBub3QgZWFzeSB0
byBmaW5kIHRoZSBjaGFuZ2VzDQo+IGJlY2F1c2UgdGhlcmUgYXJlIG1hbnkgbWVzc2FnZXMuIE15
IHN1Z2dlc3Rpb24sIGlmIGlzIHBvc3NpYmxlLCAgaXMgdG8NCj4gcHV0IHRvZ2V0aGVyIGFsbCBp
bnN0cnVjdGlvbnMgdG8gbWFrZSB0aGUgcGF0Y2ggaW4gc2FtZSBtZXNzYWdlIChmaW5hbA0KPiBt
ZXNzYWdlKS4gRm9yIG5ld2JpZXMgaXMgYmV0dGVyISA6KQ0KDQpVbmZvcnR1bmF0ZWx5LCB0aGUg
c3RhbmRhcmQgcHJhY3RpY2Ugb24gdGhpcyBtYWlsaW5nIGxpc3QgaXMgdG8gc2VuZCBhIHNlcGFy
YXRlIG1lc3NhZ2UgZm9yIGVhY2ggcGF0Y2guDQoNCj4gU28sIGFub3RoZXIgdGhpbmcgcmVsYXRl
ZCB0byBob3RwbHVnLi4uIEluIHRoaXMga2VybmVsIHZlcnNpb24gSSBjYW4gbm90DQo+IGZpbmQg
dGhlIHBjaWVocC5rbyBpbiB0aGUgc3lzdGVtLiBJJ3ZlIHRvIHJlY29tcGlsZSB0aGUga2VybmVs
IHNvdXJjZSB0bw0KPiBnZXQgdGhlIG1vZHVsZSBvciB0aGVyZSBhcmUgYW5vdGhlciBvcHRpb24g
dG8gZW5hYmxlIHRoZSBob3RwbHVnIG9uIHRoaXMNCj4ga2VybmVsIHZlcnNpb24/DQoNCnBjaWVo
cCBpcyB0aGUgaG90cGx1ZyBzdWJzeXN0ZW0gZm9yIFBDSWUsIGFuZCBpcyBjb250cm9sbGVkIGJ5
IHRoZSBLY29uZmlnIHZhbHVlIEhPVFBMVUdfUENJX1BDSUUuIEluIHRoZSBrZXJuZWwgY29uZmln
dXJhdGlvbiBzeXN0ZW0sIGxvb2sgZm9yICJQQ0kgRXhwcmVzcyBIb3RwbHVnIGRyaXZlciIgb3B0
aW9uIHVuZGVyIHRoZSAiUENJIHN1cHBvcnQiIG1lbnUuDQoNCg==

Re: [PATCH v0 00/13] PCI: Static Enumeration

[Bruno Santos]

Hello Jason,
Where I can get the source code and examples to test in RHEL 6.5?
Best regards,

Bruno Santos

Re: [PATCH v0 00/13] PCI: Static Enumeration

[Tang, Jason (ES)]

PiBGcm9tOiBCam9ybiBIZWxnYWFzIFttYWlsdG86YmhlbGdhYXNAZ29vZ2xlLmNvbV0NCj4gT24g
RnJpLCBNYXkgMjksIDIwMTUgYXQgNDoxNCBQTSwgVGFuZywgSmFzb24gKEVTKSA8SmFzb24uVGFu
ZzJAbmdjLmNvbT4NCj4gd3JvdGU6DQo+ID4gVGhpcyBicmlkZ2UgaXMgYSBDT1RTIGJyaWRnZSwg
d2l0aCBubyBzcGVjaWFsIGhvdHBsdWdnaW5nIGNhcGFiaWxpdGllcy4gSQ0KPiA+IGhhdmUgYSBu
ZWVkIHRvIGhvdC1hZGQgdGhpbmdzIHVuZGVybmVhdGggdGhhdCBicmlkZ2UuIFllcywgdGhpcyB3
aWxsDQo+ID4gcHJvYmFibHkgdm9pZCB2YXJpb3VzIHdhcnJhbnRpZXMsIGJ1dCBpbiB0ZXN0aW5n
IEkgaGF2ZSBmb3VuZCBpdCBpcw0KPiA+IGVsZWN0cmljYWxseSBzYWZlIHRvIGRvIHNvLg0KPiAN
Cj4gRG9lcyB0aGF0IG1lYW4geW91IGhhdmUgbm8gaG90cGx1ZyBldmVudHMsIGUuZy4sIGludGVy
cnVwdHMgZm9yDQo+IHByZXNlbmNlIGRldGVjdCwgYXR0ZW50aW9uIGJ1dHRvbiwgZXRjLj8gIFNv
IHdoZW4geW91IHdhbnQgdG8gaG90LWFkZA0KPiBhIGRldmljZSwgeW91IGhhdmUgdG8gbWFudWFs
bHkgImVjaG8gMSA+IC9zeXMvLi4uL3Jlc2NhbiIgb3Igc2ltaWxhcj8NCg0KWWVzLCBpbiBteSBj
YXNlIEkgaGF2ZSBub3Qgc2VlbiBhbnkgQUNQSSBldmVudHMgb3Igb3RoZXIgaW50ZXJydXB0cyBn
ZW5lcmF0ZWQNCndoZW5ldmVyIG15IHBhcnRpY3VsYXIgYnJpZGdlIGlzIGhvdCBhZGRlZC4gSSBo
YXZlIHRvIHBva2UNCi9zeXMvYnVzL3BjaS9yZXNjYW4gdG8gZm9yY2UgdGhlIGtlcm5lbCB0byBy
ZXNjYW4gdGhlIGJ1cyBhbmQgZmluZCB0aGUgbmV3DQpkZXZpY2VzLiBUaGlzIGlzIG5vdCBzdXJw
cmlzaW5nIGdpdmVuIHRoZSBkZXZpY2VzIHRoYXQgSSBoYXZlIGF2YWlsYWJsZS4NCg0K

Re: [PATCH v0 00/13] PCI: Static Enumeration

[Bjorn Helgaas]

On Fri, May 29, 2015 at 4:14 PM, Tang, Jason (ES) <Jason.Tang2@ngc.com> wrote:
>> From: Bjorn Helgaas [mailto:bhelgaas@google.com]
>> On Thu, May 28, 2015 at 11:24:45PM +0000, Tang, Jason (ES) wrote:
>> > Correct, in cases where some faulty hardware requests less memory than it
>> > really needs.
>>
>> Hmm.  This sounds potentially problematic.  Does the device have a BAR that
>> reports a size smaller than what the device actually responds to, e.g., the
>> BAR says it's 1MB, but the device actually responds to 2MB of space?
>
> Yes, on a custom PCI endpoint, it had a BAR smaller than actually used.

I recommend trying to add a quirk for this device, assuming you can
identify it via vendor/device ID or something.  That would be safer
than just assuming the broken device is only at a certain
bus/device/function address.

>> > The two places where I see 'is_hotplug_bridge' set are in
>> > quirk_hotplug_bridge() and in set_pcie_hotplug_bridge(). Both of these
>> > check that the bridge is a particular type (a PLX 6254, or if the device
>> > has the PCI_>QP_SLTCAP_HPC capability). What I propose is a more
>> general
>> > purpose that works for any PCI bridge.
>>
>> Right.  Do we set that bit for your bridge?  Those two places certainly
>> don't cover all the cases: the quirk only applies to one specific device,
>> and the other only works for bridges with native PCIe hotplug.
>>
>> If you have a different kind of bridge, is_hotplug_bridge won't be set, but
>> it probably should be.  What sort of bridge do you have?
>
> This bridge is a COTS bridge, with no special hotplugging capabilities. I
> have a need to hot-add things underneath that bridge. Yes, this will
> probably void various warranties, but in testing I have found it is
> electrically safe to do so.

Does that mean you have no hotplug events, e.g., interrupts for
presence detect, attention button, etc.?  So when you want to hot-add
a device, you have to manually "echo 1 > /sys/.../rescan" or similar?

>> This sounds like two Linux bugs: 1) we don't set is_hotplug_bridge for some
>> bridges that support hotplug, and 2) we don't reserve any bus numbers for
>> bridges that support hotplug.  If we can fix those in a generic way, it
>> will be more useful than adding a lot of code to allow users to manually
>> work around the bugs.
>
> How about: 1) Let hotplugged bridges reserve bus numbers, and then 2) let
> users declare certain bridges as hotplugable, in addition to existing
> checks?

1) sounds great; I think that would definitely improve things for
everybody.  2) sounds at least possible, too.  I don't really like
things that apply to certain devices, because there's not really a
guarantee that you can identify a device by its bus/device/function
number.  The BIOS can reassign bus numbers depending on what other
devices are in the machine.  And the OS can do the same, of course.
Linux doesn't do very much of that sort of reassignment now, but I
don't want to preclude it in the future.  But we should at least
explore it.

Bjorn

Re: [PATCH v0 00/13] PCI: Static Enumeration

[Tang, Jason (ES)]

> From: Bjorn Helgaas [mailto:bhelgaas@google.com]
> On Thu, May 28, 2015 at 11:24:45PM +0000, Tang, Jason (ES) wrote:
> > Correct, in cases where some faulty hardware requests less memory than it
> > really needs.
> 
> Hmm.  This sounds potentially problematic.  Does the device have a BAR that
> reports a size smaller than what the device actually responds to, e.g., the
> BAR says it's 1MB, but the device actually responds to 2MB of space?

Yes, on a custom PCI endpoint, it had a BAR smaller than actually used.

> > The two places where I see 'is_hotplug_bridge' set are in
> > quirk_hotplug_bridge() and in set_pcie_hotplug_bridge(). Both of these
> > check that the bridge is a particular type (a PLX 6254, or if the device
> > has the PCI_>QP_SLTCAP_HPC capability). What I propose is a more
> general
> > purpose that works for any PCI bridge.
> 
> Right.  Do we set that bit for your bridge?  Those two places certainly
> don't cover all the cases: the quirk only applies to one specific device,
> and the other only works for bridges with native PCIe hotplug.
> 
> If you have a different kind of bridge, is_hotplug_bridge won't be set, but
> it probably should be.  What sort of bridge do you have?

This bridge is a COTS bridge, with no special hotplugging capabilities. I
have a need to hot-add things underneath that bridge. Yes, this will
probably void various warranties, but in testing I have found it is
electrically safe to do so.

> This sounds like two Linux bugs: 1) we don't set is_hotplug_bridge for some
> bridges that support hotplug, and 2) we don't reserve any bus numbers for
> bridges that support hotplug.  If we can fix those in a generic way, it
> will be more useful than adding a lot of code to allow users to manually
> work around the bugs.

How about: 1) Let hotplugged bridges reserve bus numbers, and then 2) let
users declare certain bridges as hotplugable, in addition to existing
checks?

Re: [PATCH v0 00/13] PCI: Static Enumeration

[Bjorn Helgaas]

On Thu, May 28, 2015 at 11:24:45PM +0000, Tang, Jason (ES) wrote:
> > From: Bjorn Helgaas [mailto:bhelgaas@google.com]
> > On Wed, May 27, 2015 at 08:58:38PM +0000, Tang, Jason (ES) wrote:
> > > ...
> > > Q1: Doesn't PCI Hotplug already solve this problem?
> > > A1: From what I can tell, the existing PCI Hotplug infrastructure only
> > >     works with PCI endpoints; it has no way to handle hot adding a
> > >     bridge, and then later on hot adding an endpoint.
> > 
> > __pci_bus_size_bridges() uses pci_hotplug_mem_size (default 2MB,
> > overridable with "pci=hpmemsize=") to reserve space for things that may be
> > hot-added below a bridge that supports hotplug.  The thing that's added may
> > be a bridge, and that bridge might support hotplug, and it should work at
> > hot-add a device below that bridge.
> 
> Although memory could be reserved for a hot added bridge, I see no way to
> reserve bus numbers for the bridge.

OK, that makes sense.  We probably should fix that, so we can at least
handle simple hot-add cases.

> > >     Static enumeration can also be used in cases where the memory
> > >     behind a bridge needs to be changed due to faulty hardware.
> > 
> > Can you elaborate on this a bit?  Are you saying you have a piece of
> > defective hardware, and you can avoid the defect by assigning different
> > addresses to it?
> 
> Correct, in cases where some faulty hardware requests less memory than it
> really needs.

Hmm.  This sounds potentially problematic.  Does the device have a BAR that
reports a size smaller than what the device actually responds to, e.g., the
BAR says it's 1MB, but the device actually responds to 2MB of space?  It's
quite important that we know the correct size of the device so we can avoid
resource conflicts.  We might be able to deal with this by adding a quirk
to adjust the resource after we read the BAR.

> > I would expect to see a dev->is_hotplug_bridge test in the bridge
> > enumeration path (maybe somewhere in pci_scan_bridge()) so we could
> > reserve some bus numbers for future hot adds.  But I don't, so maybe
> > this is just a bug.
> 
> The two places where I see 'is_hotplug_bridge' set are in
> quirk_hotplug_bridge() and in set_pcie_hotplug_bridge(). Both of these
> check that the bridge is a particular type (a PLX 6254, or if the device
> has the PCI_>QP_SLTCAP_HPC capability). What I propose is a more general
> purpose that works for any PCI bridge.

Right.  Do we set that bit for your bridge?  Those two places certainly
don't cover all the cases: the quirk only applies to one specific device,
and the other only works for bridges with native PCIe hotplug.

If you have a different kind of bridge, is_hotplug_bridge won't be set, but
it probably should be.  What sort of bridge do you have?

> I too could not find anywhere within upstream code that reserves bus
> numbers. I suppose the next revision of these patches could:
> 
> 1. Let user mark a bridge as hotpluggable, even if it does not have the
>    capability.
> 2. If that bridge is hotpluggable, then allow user to reserve bus numbers.

This sounds like two Linux bugs: 1) we don't set is_hotplug_bridge for some
bridges that support hotplug, and 2) we don't reserve any bus numbers for
bridges that support hotplug.  If we can fix those in a generic way, it
will be more useful than adding a lot of code to allow users to manually
work around the bugs.

Bjorn

Re: [PATCH v0 00/13] PCI: Static Enumeration

[Tang, Jason (ES)]

> From: Bjorn Helgaas [mailto:bhelgaas@google.com]
> On Wed, May 27, 2015 at 08:58:38PM +0000, Tang, Jason (ES) wrote:
> > ...
> > Q1: Doesn't PCI Hotplug already solve this problem?
> > A1: From what I can tell, the existing PCI Hotplug infrastructure only
> >     works with PCI endpoints; it has no way to handle hot adding a
> >     bridge, and then later on hot adding an endpoint.
> 
> __pci_bus_size_bridges() uses pci_hotplug_mem_size (default 2MB,
> overridable with "pci=hpmemsize=") to reserve space for things that may be
> hot-added below a bridge that supports hotplug.  The thing that's added may
> be a bridge, and that bridge might support hotplug, and it should work at
> hot-add a device below that bridge.

Although memory could be reserved for a hot added bridge, I see no way to
reserve bus numbers for the bridge.

> >     Static enumeration can also be used in cases where the memory
> >     behind a bridge needs to be changed due to faulty hardware.
> 
> Can you elaborate on this a bit?  Are you saying you have a piece of
> defective hardware, and you can avoid the defect by assigning different
> addresses to it?

Correct, in cases where some faulty hardware requests less memory than it
really needs.

> I would expect to see a dev->is_hotplug_bridge test in the bridge
> enumeration path (maybe somewhere in pci_scan_bridge()) so we could
> reserve some bus numbers for future hot adds.  But I don't, so maybe
> this is just a bug.

The two places where I see 'is_hotplug_bridge' set are in
quirk_hotplug_bridge() and in set_pcie_hotplug_bridge(). Both of these
check that the bridge is a particular type (a PLX 6254, or if the device
has the PCI_>QP_SLTCAP_HPC capability). What I propose is a more general
purpose that works for any PCI bridge.

I too could not find anywhere within upstream code that reserves bus
numbers. I suppose the next revision of these patches could:

1. Let user mark a bridge as hotpluggable, even if it does not have the
   capability.
2. If that bridge is hotpluggable, then allow user to reserve bus numbers.

> There's a lot of this stuff that works fairly well as long as the BIOS has
> preconfigured things.  If your BIOS doesn't do that, I could certainly
> believe it wouldn't work as well.  I would prefer to make Linux work better
> and depend less on BIOS if we can.

Yes, these patches will override BIOS settings. At least on my system,
there is no way to force the BIOS to statically enumerate devices.

Re: [PATCH v0 00/13] PCI: Static Enumeration

[Bjorn Helgaas]

On Wed, May 27, 2015 at 08:58:38PM +0000, Tang, Jason (ES) wrote:
> ...
> Q1: Doesn't PCI Hotplug already solve this problem?
> A1: From what I can tell, the existing PCI Hotplug infrastructure only
>     works with PCI endpoints; it has no way to handle hot adding a
>     bridge, and then later on hot adding an endpoint.

__pci_bus_size_bridges() uses pci_hotplug_mem_size (default 2MB,
overridable with "pci=hpmemsize=") to reserve space for things that may be
hot-added below a bridge that supports hotplug.  The thing that's added may
be a bridge, and that bridge might support hotplug, and it should work at
hot-add a device below that bridge.

So in principle, this should work, but there might be something broken.

If you conclude it "has no way to handle hot adding a bridge," there must
be something seriously broken, and I'd like to fix that, even if it's not
sufficient to deal with your whole situation.

Can you post a complete dmesg log showing the two hot-adds and the failure?

>     Static enumeration can also be used in cases where the memory
>     behind a bridge needs to be changed due to faulty hardware.

Can you elaborate on this a bit?  Are you saying you have a piece of
defective hardware, and you can avoid the defect by assigning different
addresses to it?

> Q2: Why do bus numbers need to be reenumerated?
> A2: Consider a bus "A", with secondary bus number 1), has two child
>     buses, "B" and "C". Suppose that "B" has no grandchild buses, so
>     let its bus range is [2-2]. Likewise, "C" also has no grandchild
>     buses, so its bus range is [3-3]. Therefore, "A"'s bus range is
>     [1-3]. Let a new bridge "D" be hot added under "B". This bridge's
>     bus needs to be within its parent's bus range, but "B" has no
>     space for it. If "B" were to be dynamically resized to [2-3], then
>     "C"'s bus number would now be invalid.

I would expect to see a dev->is_hotplug_bridge test in the bridge
enumeration path (maybe somewhere in pci_scan_bridge()) so we could
reserve some bus numbers for future hot adds.  But I don't, so maybe
this is just a bug.

There's a lot of this stuff that works fairly well as long as the BIOS has
preconfigured things.  If your BIOS doesn't do that, I could certainly
believe it wouldn't work as well.  I would prefer to make Linux work better
and depend less on BIOS if we can.

Bjorn

[PATCH v0 00/13] PCI: Static Enumeration

[Tang, Jason (ES)]

Background
----------

On many architectures, PCI devices are enumerated by the BIOS prior to
the kernel booting. This is a problem if a PCI device is powered on
after the PCI subsystem has scanned the various root complexes. Whereas
PCI Hotplug devices have memory ranges reserved for them ahead of time,
no such facility exists for bridges or other endpoints.

Proposed in the upcoming patches is a mechanism similar to "static
enumeration". Via the kcmdline, the user can forcibly set secondary and
subordinate values for buses, overriding any values that the BIOS may
have set. This allows newly discovered bridges to fit into an existing
PCI tree, without causing conflicting numbers nor renumbering existing
bridges.

Next, the patches allow the user to forcibly set the memory behind a
bridge, again overriding any values the BIOS had set. This is needed to
reserve space for newly discovered endpoints' MMIO regions. The patches
employ a first-fit algorithm to pack those new MMIO BARs into the
reserved space.


Configuration
-------------

The kcmdline syntax for static enumeration is as follows:

  pci=enum=<args1>;<args2...>

Where each <arg> has the form:

  <device>@<option><option2...>

Where <device> is a PCI device described by:

  <domain>:<bus>:<slot>.<func>

And <option> is any combination of:

  B<secondary>-<subordinate>  - force secondary and subordinate bus numbers
  M<start>-<stop>  - set memory behind a bridge

All values are in hexadecimal.


Testing
-------

These patches have been tested on an x86 system that boots directly from
NVRAM. After booting to a command line, additional PCI devices were
powered. Next, a rescan was forced by echoing 1 to /sys/bus/pci/rescan;
the kernel found the new bridges and devices.


Issues
------

There are three known limitations to these patches:
  1. This only works with 32-bit PCI devices; it does not handle 64-bit
     addresses.
  2. It only works with non pre-fetched memory regions.
  3. The root filesystem must be on a non-PCI device. Reenumeration
     occurs during system initialization, prior to loading any devices.
     If an initrd normally mounts the real root filesystem from a PCI
     device, that device's addresses could change as a result of
     enumeration.


FAQs
----

Q1: Doesn't PCI Hotplug already solve this problem?
A1: From what I can tell, the existing PCI Hotplug infrastructure only
    works with PCI endpoints; it has no way to handle hot adding a
    bridge, and then later on hot adding an endpoint.

    Static enumeration can also be used in cases where the memory
    behind a bridge needs to be changed due to faulty hardware.

Q2: Why do bus numbers need to be reenumerated?
A2: Consider a bus "A", with secondary bus number 1), has two child
    buses, "B" and "C". Suppose that "B" has no grandchild buses, so
    let its bus range is [2-2]. Likewise, "C" also has no grandchild
    buses, so its bus range is [3-3]. Therefore, "A"'s bus range is
    [1-3]. Let a new bridge "D" be hot added under "B". This bridge's
    bus needs to be within its parent's bus range, but "B" has no
    space for it. If "B" were to be dynamically resized to [2-3], then
    "C"'s bus number would now be invalid.

    Any existing process that was talking to devices on "C" would need
    to be handle this sudden change in enumeration. Changes ripple
    throughout the PCI tree, as that "A" would also need to be resized.
    Obviously, this has lots of issues.

    An alternative approach, and one taken in the patches here, is to
    pre-reserve bus numbers ahead of time. If prior to user processes
    running, the kernel reads the static enumeration profile and
    changes "B"'s range to [2-3]. It can then automatically adjust "C"
    to [4-4] and thus "A" to [1-4]. Now, when bus "D" becomes active,
    it can claim bus range [3-3] without affecting any other bus.

Q3: Wouldn't the same argument of reenumerating bus numbers also apply
    to the memory window behind bridges?
A3: Yes, it would. The later patches handle this.

Q4: Why create another kernel parameter, when "pci=hpmemsize=" already
    exists?
A4: "hpmemsize" sets all bridges' memory; it does not set individual
    bridge sizes. It also does not set bus numbers.

Q5: Why use kernel parameters to specify the static enumeration profile?
A5: Because resources are allocated prior to loading drivers,
    enumeration changes must occur in drivers/pci/probe.c. The kernel
    can only access the profile from a location that does not require
    any device drivers. As such, the kernel command line fulfills these
    requirements. An additional advantage of the command line is the
    ease of disabling a profile in case of misconfiguration.

Jason Tang (13):
      PCI: Set bus's device name later
      PCI: Use child bus's number instead of max
      PCI: Add Kconfig option PCI_STATIC_ENUMERATION
      PCI: Track subordinate values in struct pci_bus
      PCI: Specify static enumeration on kcmdline
      PCI: Set secondary and subordinate bus numbers
      PCI: Calculate child's bus number based upon enumeration
      PCI: Statically specify bus memory regions
      PCI: Adjust upstream bridge memories to match static enumeration
      PCI: Invalidate resources conflicting with bridge memories
      PCI: Reassign device's MMIO BARs
      PCI: Keep searching upstream for enclosing bus
      PCI: Don't adjust settings for statically enumerated devices

 Documentation/kernel-parameters.txt |   11 +
 drivers/pci/Kconfig                 |   12 +
 drivers/pci/Makefile                |    2 +
 drivers/pci/pci.c                   |    2 +
 drivers/pci/pci.h                   |   43 +++
 drivers/pci/pci_static_enum.c       |  559 +++++++++++++++++++++++++++++++++++
 drivers/pci/probe.c                 |   45 ++-
 include/linux/pci.h                 |    7 +
 8 files changed, 675 insertions(+), 6 deletions(-)