[PATCH v2] PCI: Add information about describing PCI in ACPI

[PATCH v2] PCI: Add information about describing PCI in ACPI

[Bjorn Helgaas]

Here's another stab at this writeup.  I'd appreciate any comments!

Changes from v1 to v2:
  - Consumer/Producer is defined for Extended Address Space descriptors;
    should be ignored for QWord/DWord/Word Address Space descriptors
  - New arches may use Extended Address Space descriptors in PNP0A03 for
    bridge registers, including ECAM (if the arch adds support for this)
  - Add more details about MCFG and _CBA (Lv's suggestion)
  - Incorporate Rafael's suggestions

---

Bjorn Helgaas (1):
      PCI: Add information about describing PCI in ACPI


 Documentation/PCI/00-INDEX      |    2 
 Documentation/PCI/acpi-info.txt |  180 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 182 insertions(+)
 create mode 100644 Documentation/PCI/acpi-info.txt

[PATCH v2] PCI: Add information about describing PCI in ACPI

[Bjorn Helgaas]

Here's another stab at this writeup.  I'd appreciate any comments!

Changes from v1 to v2:
  - Consumer/Producer is defined for Extended Address Space descriptors;
    should be ignored for QWord/DWord/Word Address Space descriptors
  - New arches may use Extended Address Space descriptors in PNP0A03 for
    bridge registers, including ECAM (if the arch adds support for this)
  - Add more details about MCFG and _CBA (Lv's suggestion)
  - Incorporate Rafael's suggestions

---

Bjorn Helgaas (1):
      PCI: Add information about describing PCI in ACPI


 Documentation/PCI/00-INDEX      |    2 
 Documentation/PCI/acpi-info.txt |  180 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 182 insertions(+)
 create mode 100644 Documentation/PCI/acpi-info.txt

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2] PCI: Add information about describing PCI in ACPI

[Bjorn Helgaas]

Here's another stab at this writeup.  I'd appreciate any comments!

Changes from v1 to v2:
  - Consumer/Producer is defined for Extended Address Space descriptors;
    should be ignored for QWord/DWord/Word Address Space descriptors
  - New arches may use Extended Address Space descriptors in PNP0A03 for
    bridge registers, including ECAM (if the arch adds support for this)
  - Add more details about MCFG and _CBA (Lv's suggestion)
  - Incorporate Rafael's suggestions

---

Bjorn Helgaas (1):
      PCI: Add information about describing PCI in ACPI


 Documentation/PCI/00-INDEX      |    2 
 Documentation/PCI/acpi-info.txt |  180 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 182 insertions(+)
 create mode 100644 Documentation/PCI/acpi-info.txt

[PATCH v2] PCI: Add information about describing PCI in ACPI

[Bjorn Helgaas]

Add a writeup about how PCI host bridges should be described in ACPI
using PNP0A03/PNP0A08 devices, PNP0C02 devices, and the MCFG table.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
 Documentation/PCI/00-INDEX      |    2 
 Documentation/PCI/acpi-info.txt |  180 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 182 insertions(+)
 create mode 100644 Documentation/PCI/acpi-info.txt

diff --git a/Documentation/PCI/00-INDEX b/Documentation/PCI/00-INDEX
index 147231f..0780280 100644
--- a/Documentation/PCI/00-INDEX
+++ b/Documentation/PCI/00-INDEX
@@ -1,5 +1,7 @@
 00-INDEX
 	- this file
+acpi-info.txt
+	- info on how PCI host bridges are represented in ACPI
 MSI-HOWTO.txt
 	- the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ.
 PCIEBUS-HOWTO.txt
diff --git a/Documentation/PCI/acpi-info.txt b/Documentation/PCI/acpi-info.txt
new file mode 100644
index 0000000..06b877f
--- /dev/null
+++ b/Documentation/PCI/acpi-info.txt
@@ -0,0 +1,180 @@
+	    ACPI considerations for PCI host bridges
+
+The basic requirement is that the ACPI namespace should describe
+*everything* that consumes address space unless there's another standard
+way for the OS to find it [1, 2].  For example, windows that are forwarded
+to PCI by a PCI host bridge should be described via ACPI devices, since the
+OS can't locate the host bridge by itself.  PCI devices *below* the host
+bridge do not need to be described via ACPI, because the resources they
+consume are inside the host bridge windows, and the OS can discover them
+via the standard PCI enumeration mechanism (using config accesses to read
+and size the BARs).
+
+This ACPI resource description is done via _CRS objects of devices in the
+ACPI namespace [2].   The _CRS is like a generalized PCI BAR: the OS can
+read _CRS and figure out what resource is being consumed even if it doesn't
+have a driver for the device [3].  That's important because it means an old
+OS can work correctly even on a system with new devices unknown to the OS.
+The new devices won't do anything, but the OS can at least make sure no
+resources conflict with them.
+
+Static tables like MCFG, HPET, ECDT, etc., are *not* mechanisms for
+reserving address space!  The static tables are for things the OS needs to
+know early in boot, before it can parse the ACPI namespace.  If a new table
+is defined, an old OS needs to operate correctly even though it ignores the
+table.  _CRS allows that because it is generic and understood by the old
+OS; a static table does not.
+
+If the OS is expected to manage a non-discoverable device described via
+ACPI, that device will have a specific _HID/_CID that tells the OS what
+driver to bind to it, and the _CRS tells the OS and the driver where the
+device's registers are.
+
+PCI host bridges are PNP0A03 or PNP0A08 devices.  Their _CRS should
+describe all the address space they consume.  This includes all the windows
+they forward down to the PCI bus, as well as bridge registers that are not
+forwarded to PCI.  The bridge registers include things like secondary/
+subordinate bus registers that determine the bus range below the bridge,
+window registers that describe the apertures, etc.  These are all
+device-specific, non-architected things, so the only way a PNP0A03/PNP0A08
+driver can manage them is via _PRS/_CRS/_SRS, which contain the
+device-specific details.  The bridge registers also include ECAM space,
+since it is consumed by the bridge.
+
+ACPI defines a Consumer/Producer bit to distinguish the bridge registers
+("Consumer") from the bridge apertures ("Producer") [4, 5], but early
+BIOSes didn't use that bit correctly.  The result is that the current ACPI
+spec defines Consumer/Producer only for the relatively new Extended Address
+Space descriptors; the bit should be ignored in the older QWord/DWord/Word
+Address Space descriptors.  Consequently, OSes have to assume all
+QWord/DWord/Word descriptors are windows.
+
+Prior to the addition of Extended Address Space descriptors, the failure of
+Consumer/Producer meant there was no way to describe bridge registers in
+the PNP0A03/PNP0A08 device itself.  The workaround was to describe the
+bridge registers (including ECAM space) in PNP0C02 catch-all devices [6].
+With the exception of ECAM, the bridge register space is device-specific
+anyway, so the generic PNP0A03/PNP0A08 driver (pci_root.c) has no need to
+know about it.  
+
+New architectures should be able to use "Consumer" Extended Address Space
+descriptors in the PNP0A03 device for bridge registers, including ECAM,
+although a strict interpretation of [6] might prohibit this.  Old x86 and
+ia64 kernels assume all address space descriptors, including "Consumer"
+Extended Address Space ones, are windows, so it would not be safe to
+describe bridge registers this way on those architectures.
+
+PNP0C02 "motherboard" devices are basically a catch-all.  There's no
+programming model for them other than "don't use these resources for
+anything else."  So a PNP0C02 _CRS should claim any address space that is
+(1) not claimed by _CRS under any other device object in the ACPI namespace
+and (2) should not be assigned by the OS to something else.
+
+The PCIe spec requires the Enhanced Configuration Access Method (ECAM)
+unless there's a standard firmware interface for config access, e.g., the
+ia64 SAL interface [7].  A host bridge consumes ECAM memory address space
+and converts memory accesses into PCI configuration accesses.  The spec
+defines the ECAM address space layout and functionality; only the base of
+the address space is device-specific.  An ACPI OS learns the base address
+from either the static MCFG table or a _CBA method in the PNP0A03 device.
+
+The MCFG table must describe the ECAM space of non-hot pluggable host
+bridges [8].  Since MCFG is a static table and can't be updated by hotplug,
+a _CBA method in the PNP0A03 device describes the ECAM space of a
+hot-pluggable host bridge [9].  Note that for both MCFG and _CBA, the base
+address always corresponds to bus 0, even if the bus range below the bridge
+(which is reported via _CRS) doesn't start at 0.
+
+
+[1] ACPI 6.0, sec 6.1:
+    For any device that is on a non-enumerable type of bus (for example, an
+    ISA bus), OSPM enumerates the devices' identifier(s) and the ACPI
+    system firmware must supply an _HID object ... for each device to
+    enable OSPM to do that.
+
+[2] ACPI 6.0, sec 3.7:
+    The OS enumerates motherboard devices simply by reading through the
+    ACPI Namespace looking for devices with hardware IDs.
+
+    Each device enumerated by ACPI includes ACPI-defined objects in the
+    ACPI Namespace that report the hardware resources the device could
+    occupy [_PRS], an object that reports the resources that are currently
+    used by the device [_CRS], and objects for configuring those resources
+    [_SRS].  The information is used by the Plug and Play OS (OSPM) to
+    configure the devices.
+
+[3] ACPI 6.0, sec 6.2:
+    OSPM uses device configuration objects to configure hardware resources
+    for devices enumerated via ACPI.  Device configuration objects provide
+    information about current and possible resource requirements, the
+    relationship between shared resources, and methods for configuring
+    hardware resources.
+
+    When OSPM enumerates a device, it calls _PRS to determine the resource
+    requirements of the device.  It may also call _CRS to find the current
+    resource settings for the device.  Using this information, the Plug and
+    Play system determines what resources the device should consume and
+    sets those resources by calling the device’s _SRS control method.
+
+    In ACPI, devices can consume resources (for example, legacy keyboards),
+    provide resources (for example, a proprietary PCI bridge), or do both.
+    Unless otherwise specified, resources for a device are assumed to be
+    taken from the nearest matching resource above the device in the device
+    hierarchy.
+
+[4] ACPI 6.0, sec 6.4.3.5.1, 2, 3, 4:
+    QWord/DWord/Word Address Space Descriptor (.1, .2, .3)
+    General Flags: Bit [0] Ignored
+
+    Extended Address Space Descriptor (.4)
+    General Flags: Bit [0] Consumer/Producer:
+	1–This device consumes this resource
+	0–This device produces and consumes this resource
+
+[5] ACPI 6.0, sec 19.6.43:
+    ResourceUsage specifies whether the Memory range is consumed by
+    this device (ResourceConsumer) or passed on to child devices
+    (ResourceProducer).  If nothing is specified, then
+    ResourceConsumer is assumed.
+
+[6] PCI Firmware 3.0, sec 4.1.2:
+    If the operating system does not natively comprehend reserving the
+    MMCFG region, the MMCFG region must be reserved by firmware.  The
+    address range reported in the MCFG table or by _CBA method (see Section
+    4.1.3) must be reserved by declaring a motherboard resource.  For most
+    systems, the motherboard resource would appear at the root of the ACPI
+    namespace (under \_SB) in a node with a _HID of EISAID (PNP0C02), and
+    the resources in this case should not be claimed in the root PCI bus’s
+    _CRS.  The resources can optionally be returned in Int15 E820 or
+    EFIGetMemoryMap as reserved memory but must always be reported through
+    ACPI as a motherboard resource.
+
+[7] PCI Express 3.0, sec 7.2.2:
+    For systems that are PC-compatible, or that do not implement a
+    processor-architecture-specific firmware interface standard that allows
+    access to the Configuration Space, the ECAM is required as defined in
+    this section.
+
+[8] PCI Firmware 3.0, sec 4.1.2:
+    The MCFG table is an ACPI table that is used to communicate the base
+    addresses corresponding to the non-hot removable PCI Segment Groups
+    range within a PCI Segment Group available to the operating system at
+    boot. This is required for the PC-compatible systems.
+
+    The MCFG table is only used to communicate the base addresses
+    corresponding to the PCI Segment Groups available to the system at
+    boot.
+
+[9] PCI Firmware 3.0, sec 4.1.3:
+    The _CBA (Memory mapped Configuration Base Address) control method is
+    an optional ACPI object that returns the 64-bit memory mapped
+    configuration base address for the hot plug capable host bridge. The
+    base address returned by _CBA is processor-relative address. The _CBA
+    control method evaluates to an Integer.
+
+    This control method appears under a host bridge object. When the _CBA
+    method appears under an active host bridge object, the operating system
+    evaluates this structure to identify the memory mapped configuration
+    base address corresponding to the PCI Segment Group for the bus number
+    range specified in _CRS method. An ACPI name space object that contains
+    the _CBA method must also contain a corresponding _SEG method.

[PATCH v2] PCI: Add information about describing PCI in ACPI

[Bjorn Helgaas]

QWRkIGEgd3JpdGV1cCBhYm91dCBob3cgUENJIGhvc3QgYnJpZGdlcyBzaG91bGQgYmUgZGVzY3Jp
YmVkIGluIEFDUEkKdXNpbmcgUE5QMEEwMy9QTlAwQTA4IGRldmljZXMsIFBOUDBDMDIgZGV2aWNl
cywgYW5kIHRoZSBNQ0ZHIHRhYmxlLgoKU2lnbmVkLW9mZi1ieTogQmpvcm4gSGVsZ2FhcyA8Ymhl
bGdhYXNAZ29vZ2xlLmNvbT4KLS0tCiBEb2N1bWVudGF0aW9uL1BDSS8wMC1JTkRFWCAgICAgIHwg
ICAgMiAKIERvY3VtZW50YXRpb24vUENJL2FjcGktaW5mby50eHQgfCAgMTgwICsrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKwogMiBmaWxlcyBjaGFuZ2VkLCAxODIgaW5zZXJ0
aW9ucygrKQogY3JlYXRlIG1vZGUgMTAwNjQ0IERvY3VtZW50YXRpb24vUENJL2FjcGktaW5mby50
eHQKCmRpZmYgLS1naXQgYS9Eb2N1bWVudGF0aW9uL1BDSS8wMC1JTkRFWCBiL0RvY3VtZW50YXRp
b24vUENJLzAwLUlOREVYCmluZGV4IDE0NzIzMWYuLjA3ODAyODAgMTAwNjQ0Ci0tLSBhL0RvY3Vt
ZW50YXRpb24vUENJLzAwLUlOREVYCisrKyBiL0RvY3VtZW50YXRpb24vUENJLzAwLUlOREVYCkBA
IC0xLDUgKzEsNyBAQAogMDAtSU5ERVgKIAktIHRoaXMgZmlsZQorYWNwaS1pbmZvLnR4dAorCS0g
aW5mbyBvbiBob3cgUENJIGhvc3QgYnJpZGdlcyBhcmUgcmVwcmVzZW50ZWQgaW4gQUNQSQogTVNJ
LUhPV1RPLnR4dAogCS0gdGhlIE1lc3NhZ2UgU2lnbmFsZWQgSW50ZXJydXB0cyAoTVNJKSBEcml2
ZXIgR3VpZGUgSE9XVE8gYW5kIEZBUS4KIFBDSUVCVVMtSE9XVE8udHh0CmRpZmYgLS1naXQgYS9E
b2N1bWVudGF0aW9uL1BDSS9hY3BpLWluZm8udHh0IGIvRG9jdW1lbnRhdGlvbi9QQ0kvYWNwaS1p
bmZvLnR4dApuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi4wNmI4NzdmCi0tLSAv
ZGV2L251bGwKKysrIGIvRG9jdW1lbnRhdGlvbi9QQ0kvYWNwaS1pbmZvLnR4dApAQCAtMCwwICsx
LDE4MCBAQAorCSAgICBBQ1BJIGNvbnNpZGVyYXRpb25zIGZvciBQQ0kgaG9zdCBicmlkZ2VzCisK
K1RoZSBiYXNpYyByZXF1aXJlbWVudCBpcyB0aGF0IHRoZSBBQ1BJIG5hbWVzcGFjZSBzaG91bGQg
ZGVzY3JpYmUKKypldmVyeXRoaW5nKiB0aGF0IGNvbnN1bWVzIGFkZHJlc3Mgc3BhY2UgdW5sZXNz
IHRoZXJlJ3MgYW5vdGhlciBzdGFuZGFyZAord2F5IGZvciB0aGUgT1MgdG8gZmluZCBpdCBbMSwg
Ml0uIMKgRm9yIGV4YW1wbGUsIHdpbmRvd3MgdGhhdCBhcmUgZm9yd2FyZGVkCit0byBQQ0kgYnkg
YSBQQ0kgaG9zdCBicmlkZ2Ugc2hvdWxkIGJlIGRlc2NyaWJlZCB2aWEgQUNQSSBkZXZpY2VzLCBz
aW5jZSB0aGUKK09TIGNhbid0IGxvY2F0ZSB0aGUgaG9zdCBicmlkZ2UgYnkgaXRzZWxmLiDCoFBD
SSBkZXZpY2VzICpiZWxvdyogdGhlIGhvc3QKK2JyaWRnZSBkbyBub3QgbmVlZCB0byBiZSBkZXNj
cmliZWQgdmlhIEFDUEksIGJlY2F1c2UgdGhlIHJlc291cmNlcyB0aGV5Citjb25zdW1lIGFyZSBp
bnNpZGUgdGhlIGhvc3QgYnJpZGdlIHdpbmRvd3MsIGFuZCB0aGUgT1MgY2FuIGRpc2NvdmVyIHRo
ZW0KK3ZpYSB0aGUgc3RhbmRhcmQgUENJIGVudW1lcmF0aW9uIG1lY2hhbmlzbSAodXNpbmcgY29u
ZmlnIGFjY2Vzc2VzIHRvIHJlYWQKK2FuZCBzaXplIHRoZSBCQVJzKS4KKworVGhpcyBBQ1BJIHJl
c291cmNlIGRlc2NyaXB0aW9uIGlzIGRvbmUgdmlhIF9DUlMgb2JqZWN0cyBvZiBkZXZpY2VzIGlu
IHRoZQorQUNQSSBuYW1lc3BhY2UgWzJdLiDCoCBUaGUgX0NSUyBpcyBsaWtlIGEgZ2VuZXJhbGl6
ZWQgUENJIEJBUjogdGhlIE9TIGNhbgorcmVhZCBfQ1JTIGFuZCBmaWd1cmUgb3V0IHdoYXQgcmVz
b3VyY2UgaXMgYmVpbmcgY29uc3VtZWQgZXZlbiBpZiBpdCBkb2Vzbid0CitoYXZlIGEgZHJpdmVy
IGZvciB0aGUgZGV2aWNlIFszXS4gwqBUaGF0J3MgaW1wb3J0YW50IGJlY2F1c2UgaXQgbWVhbnMg
YW4gb2xkCitPUyBjYW4gd29yayBjb3JyZWN0bHkgZXZlbiBvbiBhIHN5c3RlbSB3aXRoIG5ldyBk
ZXZpY2VzIHVua25vd24gdG8gdGhlIE9TLgorVGhlIG5ldyBkZXZpY2VzIHdvbid0IGRvIGFueXRo
aW5nLCBidXQgdGhlIE9TIGNhbiBhdCBsZWFzdCBtYWtlIHN1cmUgbm8KK3Jlc291cmNlcyBjb25m
bGljdCB3aXRoIHRoZW0uCisKK1N0YXRpYyB0YWJsZXMgbGlrZSBNQ0ZHLCBIUEVULCBFQ0RULCBl
dGMuLCBhcmUgKm5vdCogbWVjaGFuaXNtcyBmb3IKK3Jlc2VydmluZyBhZGRyZXNzIHNwYWNlISAg
VGhlIHN0YXRpYyB0YWJsZXMgYXJlIGZvciB0aGluZ3MgdGhlIE9TIG5lZWRzIHRvCitrbm93IGVh
cmx5IGluIGJvb3QsIGJlZm9yZSBpdCBjYW4gcGFyc2UgdGhlIEFDUEkgbmFtZXNwYWNlLiAgSWYg
YSBuZXcgdGFibGUKK2lzIGRlZmluZWQsIGFuIG9sZCBPUyBuZWVkcyB0byBvcGVyYXRlIGNvcnJl
Y3RseSBldmVuIHRob3VnaCBpdCBpZ25vcmVzIHRoZQordGFibGUuICBfQ1JTIGFsbG93cyB0aGF0
IGJlY2F1c2UgaXQgaXMgZ2VuZXJpYyBhbmQgdW5kZXJzdG9vZCBieSB0aGUgb2xkCitPUzsgYSBz
dGF0aWMgdGFibGUgZG9lcyBub3QuCisKK0lmIHRoZSBPUyBpcyBleHBlY3RlZCB0byBtYW5hZ2Ug
YSBub24tZGlzY292ZXJhYmxlIGRldmljZSBkZXNjcmliZWQgdmlhCitBQ1BJLCB0aGF0IGRldmlj
ZSB3aWxsIGhhdmUgYSBzcGVjaWZpYyBfSElEL19DSUQgdGhhdCB0ZWxscyB0aGUgT1Mgd2hhdAor
ZHJpdmVyIHRvIGJpbmQgdG8gaXQsIGFuZCB0aGUgX0NSUyB0ZWxscyB0aGUgT1MgYW5kIHRoZSBk
cml2ZXIgd2hlcmUgdGhlCitkZXZpY2UncyByZWdpc3RlcnMgYXJlLgorCitQQ0kgaG9zdCBicmlk
Z2VzIGFyZSBQTlAwQTAzIG9yIFBOUDBBMDggZGV2aWNlcy4gwqBUaGVpciBfQ1JTIHNob3VsZAor
ZGVzY3JpYmUgYWxsIHRoZSBhZGRyZXNzIHNwYWNlIHRoZXkgY29uc3VtZS4gwqBUaGlzIGluY2x1
ZGVzIGFsbCB0aGUgd2luZG93cwordGhleSBmb3J3YXJkIGRvd24gdG8gdGhlIFBDSSBidXMsIGFz
IHdlbGwgYXMgYnJpZGdlIHJlZ2lzdGVycyB0aGF0IGFyZSBub3QKK2ZvcndhcmRlZCB0byBQQ0ku
IMKgVGhlIGJyaWRnZSByZWdpc3RlcnMgaW5jbHVkZSB0aGluZ3MgbGlrZSBzZWNvbmRhcnkvCitz
dWJvcmRpbmF0ZSBidXMgcmVnaXN0ZXJzIHRoYXQgZGV0ZXJtaW5lIHRoZSBidXMgcmFuZ2UgYmVs
b3cgdGhlIGJyaWRnZSwKK3dpbmRvdyByZWdpc3RlcnMgdGhhdCBkZXNjcmliZSB0aGUgYXBlcnR1
cmVzLCBldGMuIMKgVGhlc2UgYXJlIGFsbAorZGV2aWNlLXNwZWNpZmljLCBub24tYXJjaGl0ZWN0
ZWQgdGhpbmdzLCBzbyB0aGUgb25seSB3YXkgYSBQTlAwQTAzL1BOUDBBMDgKK2RyaXZlciBjYW4g
bWFuYWdlIHRoZW0gaXMgdmlhIF9QUlMvX0NSUy9fU1JTLCB3aGljaCBjb250YWluIHRoZQorZGV2
aWNlLXNwZWNpZmljIGRldGFpbHMuIMKgVGhlIGJyaWRnZSByZWdpc3RlcnMgYWxzbyBpbmNsdWRl
IEVDQU0gc3BhY2UsCitzaW5jZSBpdCBpcyBjb25zdW1lZCBieSB0aGUgYnJpZGdlLgorCitBQ1BJ
IGRlZmluZXMgYSBDb25zdW1lci9Qcm9kdWNlciBiaXQgdG8gZGlzdGluZ3Vpc2ggdGhlIGJyaWRn
ZSByZWdpc3RlcnMKKygiQ29uc3VtZXIiKSBmcm9tIHRoZSBicmlkZ2UgYXBlcnR1cmVzICgiUHJv
ZHVjZXIiKSBbNCwgNV0sIGJ1dCBlYXJseQorQklPU2VzIGRpZG4ndCB1c2UgdGhhdCBiaXQgY29y
cmVjdGx5LiAgVGhlIHJlc3VsdCBpcyB0aGF0IHRoZSBjdXJyZW50IEFDUEkKK3NwZWMgZGVmaW5l
cyBDb25zdW1lci9Qcm9kdWNlciBvbmx5IGZvciB0aGUgcmVsYXRpdmVseSBuZXcgRXh0ZW5kZWQg
QWRkcmVzcworU3BhY2UgZGVzY3JpcHRvcnM7IHRoZSBiaXQgc2hvdWxkIGJlIGlnbm9yZWQgaW4g
dGhlIG9sZGVyIFFXb3JkL0RXb3JkL1dvcmQKK0FkZHJlc3MgU3BhY2UgZGVzY3JpcHRvcnMuICBD
b25zZXF1ZW50bHksIE9TZXMgaGF2ZSB0byBhc3N1bWUgYWxsCitRV29yZC9EV29yZC9Xb3JkIGRl
c2NyaXB0b3JzIGFyZSB3aW5kb3dzLgorCitQcmlvciB0byB0aGUgYWRkaXRpb24gb2YgRXh0ZW5k
ZWQgQWRkcmVzcyBTcGFjZSBkZXNjcmlwdG9ycywgdGhlIGZhaWx1cmUgb2YKK0NvbnN1bWVyL1By
b2R1Y2VyIG1lYW50IHRoZXJlIHdhcyBubyB3YXkgdG8gZGVzY3JpYmUgYnJpZGdlIHJlZ2lzdGVy
cyBpbgordGhlIFBOUDBBMDMvUE5QMEEwOCBkZXZpY2UgaXRzZWxmLiAgVGhlIHdvcmthcm91bmQg
d2FzIHRvIGRlc2NyaWJlIHRoZQorYnJpZGdlIHJlZ2lzdGVycyAoaW5jbHVkaW5nIEVDQU0gc3Bh
Y2UpIGluIFBOUDBDMDIgY2F0Y2gtYWxsIGRldmljZXMgWzZdLgorV2l0aCB0aGUgZXhjZXB0aW9u
IG9mIEVDQU0sIHRoZSBicmlkZ2UgcmVnaXN0ZXIgc3BhY2UgaXMgZGV2aWNlLXNwZWNpZmljCith
bnl3YXksIHNvIHRoZSBnZW5lcmljIFBOUDBBMDMvUE5QMEEwOCBkcml2ZXIgKHBjaV9yb290LmMp
IGhhcyBubyBuZWVkIHRvCitrbm93IGFib3V0IGl0LiDCoAorCitOZXcgYXJjaGl0ZWN0dXJlcyBz
aG91bGQgYmUgYWJsZSB0byB1c2UgIkNvbnN1bWVyIiBFeHRlbmRlZCBBZGRyZXNzIFNwYWNlCitk
ZXNjcmlwdG9ycyBpbiB0aGUgUE5QMEEwMyBkZXZpY2UgZm9yIGJyaWRnZSByZWdpc3RlcnMsIGlu
Y2x1ZGluZyBFQ0FNLAorYWx0aG91Z2ggYSBzdHJpY3QgaW50ZXJwcmV0YXRpb24gb2YgWzZdIG1p
Z2h0IHByb2hpYml0IHRoaXMuICBPbGQgeDg2IGFuZAoraWE2NCBrZXJuZWxzIGFzc3VtZSBhbGwg
YWRkcmVzcyBzcGFjZSBkZXNjcmlwdG9ycywgaW5jbHVkaW5nICJDb25zdW1lciIKK0V4dGVuZGVk
IEFkZHJlc3MgU3BhY2Ugb25lcywgYXJlIHdpbmRvd3MsIHNvIGl0IHdvdWxkIG5vdCBiZSBzYWZl
IHRvCitkZXNjcmliZSBicmlkZ2UgcmVnaXN0ZXJzIHRoaXMgd2F5IG9uIHRob3NlIGFyY2hpdGVj
dHVyZXMuCisKK1BOUDBDMDIgIm1vdGhlcmJvYXJkIiBkZXZpY2VzIGFyZSBiYXNpY2FsbHkgYSBj
YXRjaC1hbGwuIMKgVGhlcmUncyBubworcHJvZ3JhbW1pbmcgbW9kZWwgZm9yIHRoZW0gb3RoZXIg
dGhhbiAiZG9uJ3QgdXNlIHRoZXNlIHJlc291cmNlcyBmb3IKK2FueXRoaW5nIGVsc2UuIiDCoFNv
IGEgUE5QMEMwMiBfQ1JTIHNob3VsZCBjbGFpbSBhbnkgYWRkcmVzcyBzcGFjZSB0aGF0IGlzCiso
MSkgbm90IGNsYWltZWQgYnkgX0NSUyB1bmRlciBhbnkgb3RoZXIgZGV2aWNlIG9iamVjdCBpbiB0
aGUgQUNQSSBuYW1lc3BhY2UKK2FuZCAoMikgc2hvdWxkIG5vdCBiZSBhc3NpZ25lZCBieSB0aGUg
T1MgdG8gc29tZXRoaW5nIGVsc2UuCisKK1RoZSBQQ0llIHNwZWMgcmVxdWlyZXMgdGhlIEVuaGFu
Y2VkIENvbmZpZ3VyYXRpb24gQWNjZXNzIE1ldGhvZCAoRUNBTSkKK3VubGVzcyB0aGVyZSdzIGEg
c3RhbmRhcmQgZmlybXdhcmUgaW50ZXJmYWNlIGZvciBjb25maWcgYWNjZXNzLCBlLmcuLCB0aGUK
K2lhNjQgU0FMIGludGVyZmFjZSBbN10uICBBIGhvc3QgYnJpZGdlIGNvbnN1bWVzIEVDQU0gbWVt
b3J5IGFkZHJlc3Mgc3BhY2UKK2FuZCBjb252ZXJ0cyBtZW1vcnkgYWNjZXNzZXMgaW50byBQQ0kg
Y29uZmlndXJhdGlvbiBhY2Nlc3Nlcy4gIFRoZSBzcGVjCitkZWZpbmVzIHRoZSBFQ0FNIGFkZHJl
c3Mgc3BhY2UgbGF5b3V0IGFuZCBmdW5jdGlvbmFsaXR5OyBvbmx5IHRoZSBiYXNlIG9mCit0aGUg
YWRkcmVzcyBzcGFjZSBpcyBkZXZpY2Utc3BlY2lmaWMuICBBbiBBQ1BJIE9TIGxlYXJucyB0aGUg
YmFzZSBhZGRyZXNzCitmcm9tIGVpdGhlciB0aGUgc3RhdGljIE1DRkcgdGFibGUgb3IgYSBfQ0JB
IG1ldGhvZCBpbiB0aGUgUE5QMEEwMyBkZXZpY2UuCisKK1RoZSBNQ0ZHIHRhYmxlIG11c3QgZGVz
Y3JpYmUgdGhlIEVDQU0gc3BhY2Ugb2Ygbm9uLWhvdCBwbHVnZ2FibGUgaG9zdAorYnJpZGdlcyBb
OF0uICBTaW5jZSBNQ0ZHIGlzIGEgc3RhdGljIHRhYmxlIGFuZCBjYW4ndCBiZSB1cGRhdGVkIGJ5
IGhvdHBsdWcsCithIF9DQkEgbWV0aG9kIGluIHRoZSBQTlAwQTAzIGRldmljZSBkZXNjcmliZXMg
dGhlIEVDQU0gc3BhY2Ugb2YgYQoraG90LXBsdWdnYWJsZSBob3N0IGJyaWRnZSBbOV0uICBOb3Rl
IHRoYXQgZm9yIGJvdGggTUNGRyBhbmQgX0NCQSwgdGhlIGJhc2UKK2FkZHJlc3MgYWx3YXlzIGNv
cnJlc3BvbmRzIHRvIGJ1cyAwLCBldmVuIGlmIHRoZSBidXMgcmFuZ2UgYmVsb3cgdGhlIGJyaWRn
ZQorKHdoaWNoIGlzIHJlcG9ydGVkIHZpYSBfQ1JTKSBkb2Vzbid0IHN0YXJ0IGF0IDAuCisKKwor
WzFdIEFDUEkgNi4wLCBzZWMgNi4xOgorICAgIEZvciBhbnkgZGV2aWNlIHRoYXQgaXMgb24gYSBu
b24tZW51bWVyYWJsZSB0eXBlIG9mIGJ1cyAoZm9yIGV4YW1wbGUsIGFuCisgICAgSVNBIGJ1cyks
IE9TUE0gZW51bWVyYXRlcyB0aGUgZGV2aWNlcycgaWRlbnRpZmllcihzKSBhbmQgdGhlIEFDUEkK
KyAgICBzeXN0ZW0gZmlybXdhcmUgbXVzdCBzdXBwbHkgYW4gX0hJRCBvYmplY3QgLi4uIGZvciBl
YWNoIGRldmljZSB0bworICAgIGVuYWJsZSBPU1BNIHRvIGRvIHRoYXQuCisKK1syXSBBQ1BJIDYu
MCwgc2VjIDMuNzoKKyAgICBUaGUgT1MgZW51bWVyYXRlcyBtb3RoZXJib2FyZCBkZXZpY2VzIHNp
bXBseSBieSByZWFkaW5nIHRocm91Z2ggdGhlCisgICAgQUNQSSBOYW1lc3BhY2UgbG9va2luZyBm
b3IgZGV2aWNlcyB3aXRoIGhhcmR3YXJlIElEcy4KKworICAgIEVhY2ggZGV2aWNlIGVudW1lcmF0
ZWQgYnkgQUNQSSBpbmNsdWRlcyBBQ1BJLWRlZmluZWQgb2JqZWN0cyBpbiB0aGUKKyAgICBBQ1BJ
IE5hbWVzcGFjZSB0aGF0IHJlcG9ydCB0aGUgaGFyZHdhcmUgcmVzb3VyY2VzIHRoZSBkZXZpY2Ug
Y291bGQKKyAgICBvY2N1cHkgW19QUlNdLCBhbiBvYmplY3QgdGhhdCByZXBvcnRzIHRoZSByZXNv
dXJjZXMgdGhhdCBhcmUgY3VycmVudGx5CisgICAgdXNlZCBieSB0aGUgZGV2aWNlIFtfQ1JTXSwg
YW5kIG9iamVjdHMgZm9yIGNvbmZpZ3VyaW5nIHRob3NlIHJlc291cmNlcworICAgIFtfU1JTXS4g
IFRoZSBpbmZvcm1hdGlvbiBpcyB1c2VkIGJ5IHRoZSBQbHVnIGFuZCBQbGF5IE9TIChPU1BNKSB0
bworICAgIGNvbmZpZ3VyZSB0aGUgZGV2aWNlcy4KKworWzNdIEFDUEkgNi4wLCBzZWMgNi4yOgor
ICAgIE9TUE0gdXNlcyBkZXZpY2UgY29uZmlndXJhdGlvbiBvYmplY3RzIHRvIGNvbmZpZ3VyZSBo
YXJkd2FyZSByZXNvdXJjZXMKKyAgICBmb3IgZGV2aWNlcyBlbnVtZXJhdGVkIHZpYSBBQ1BJLiAg
RGV2aWNlIGNvbmZpZ3VyYXRpb24gb2JqZWN0cyBwcm92aWRlCisgICAgaW5mb3JtYXRpb24gYWJv
dXQgY3VycmVudCBhbmQgcG9zc2libGUgcmVzb3VyY2UgcmVxdWlyZW1lbnRzLCB0aGUKKyAgICBy
ZWxhdGlvbnNoaXAgYmV0d2VlbiBzaGFyZWQgcmVzb3VyY2VzLCBhbmQgbWV0aG9kcyBmb3IgY29u
ZmlndXJpbmcKKyAgICBoYXJkd2FyZSByZXNvdXJjZXMuCisKKyAgICBXaGVuIE9TUE0gZW51bWVy
YXRlcyBhIGRldmljZSwgaXQgY2FsbHMgX1BSUyB0byBkZXRlcm1pbmUgdGhlIHJlc291cmNlCisg
ICAgcmVxdWlyZW1lbnRzIG9mIHRoZSBkZXZpY2UuICBJdCBtYXkgYWxzbyBjYWxsIF9DUlMgdG8g
ZmluZCB0aGUgY3VycmVudAorICAgIHJlc291cmNlIHNldHRpbmdzIGZvciB0aGUgZGV2aWNlLiAg
VXNpbmcgdGhpcyBpbmZvcm1hdGlvbiwgdGhlIFBsdWcgYW5kCisgICAgUGxheSBzeXN0ZW0gZGV0
ZXJtaW5lcyB3aGF0IHJlc291cmNlcyB0aGUgZGV2aWNlIHNob3VsZCBjb25zdW1lIGFuZAorICAg
IHNldHMgdGhvc2UgcmVzb3VyY2VzIGJ5IGNhbGxpbmcgdGhlIGRldmljZeKAmXMgX1NSUyBjb250
cm9sIG1ldGhvZC4KKworICAgIEluIEFDUEksIGRldmljZXMgY2FuIGNvbnN1bWUgcmVzb3VyY2Vz
IChmb3IgZXhhbXBsZSwgbGVnYWN5IGtleWJvYXJkcyksCisgICAgcHJvdmlkZSByZXNvdXJjZXMg
KGZvciBleGFtcGxlLCBhIHByb3ByaWV0YXJ5IFBDSSBicmlkZ2UpLCBvciBkbyBib3RoLgorICAg
IFVubGVzcyBvdGhlcndpc2Ugc3BlY2lmaWVkLCByZXNvdXJjZXMgZm9yIGEgZGV2aWNlIGFyZSBh
c3N1bWVkIHRvIGJlCisgICAgdGFrZW4gZnJvbSB0aGUgbmVhcmVzdCBtYXRjaGluZyByZXNvdXJj
ZSBhYm92ZSB0aGUgZGV2aWNlIGluIHRoZSBkZXZpY2UKKyAgICBoaWVyYXJjaHkuCisKK1s0XSBB
Q1BJIDYuMCwgc2VjIDYuNC4zLjUuMSwgMiwgMywgNDoKKyAgICBRV29yZC9EV29yZC9Xb3JkIEFk
ZHJlc3MgU3BhY2UgRGVzY3JpcHRvciAoLjEsIC4yLCAuMykKKyAgICBHZW5lcmFsIEZsYWdzOiBC
aXQgWzBdIElnbm9yZWQKKworICAgIEV4dGVuZGVkIEFkZHJlc3MgU3BhY2UgRGVzY3JpcHRvciAo
LjQpCisgICAgR2VuZXJhbCBGbGFnczogQml0IFswXSBDb25zdW1lci9Qcm9kdWNlcjoKKwkx4oCT
VGhpcyBkZXZpY2UgY29uc3VtZXMgdGhpcyByZXNvdXJjZQorCTDigJNUaGlzIGRldmljZSBwcm9k
dWNlcyBhbmQgY29uc3VtZXMgdGhpcyByZXNvdXJjZQorCitbNV0gQUNQSSA2LjAsIHNlYyAxOS42
LjQzOgorICAgIFJlc291cmNlVXNhZ2Ugc3BlY2lmaWVzIHdoZXRoZXIgdGhlIE1lbW9yeSByYW5n
ZSBpcyBjb25zdW1lZCBieQorICAgIHRoaXMgZGV2aWNlIChSZXNvdXJjZUNvbnN1bWVyKSBvciBw
YXNzZWQgb24gdG8gY2hpbGQgZGV2aWNlcworICAgIChSZXNvdXJjZVByb2R1Y2VyKS4gIElmIG5v
dGhpbmcgaXMgc3BlY2lmaWVkLCB0aGVuCisgICAgUmVzb3VyY2VDb25zdW1lciBpcyBhc3N1bWVk
LgorCitbNl0gUENJIEZpcm13YXJlIDMuMCwgc2VjIDQuMS4yOgorICAgIElmIHRoZSBvcGVyYXRp
bmcgc3lzdGVtIGRvZXMgbm90IG5hdGl2ZWx5IGNvbXByZWhlbmQgcmVzZXJ2aW5nIHRoZQorICAg
IE1NQ0ZHIHJlZ2lvbiwgdGhlIE1NQ0ZHIHJlZ2lvbiBtdXN0IGJlIHJlc2VydmVkIGJ5IGZpcm13
YXJlLiAgVGhlCisgICAgYWRkcmVzcyByYW5nZSByZXBvcnRlZCBpbiB0aGUgTUNGRyB0YWJsZSBv
ciBieSBfQ0JBIG1ldGhvZCAoc2VlIFNlY3Rpb24KKyAgICA0LjEuMykgbXVzdCBiZSByZXNlcnZl
ZCBieSBkZWNsYXJpbmcgYSBtb3RoZXJib2FyZCByZXNvdXJjZS4gIEZvciBtb3N0CisgICAgc3lz
dGVtcywgdGhlIG1vdGhlcmJvYXJkIHJlc291cmNlIHdvdWxkIGFwcGVhciBhdCB0aGUgcm9vdCBv
ZiB0aGUgQUNQSQorICAgIG5hbWVzcGFjZSAodW5kZXIgXF9TQikgaW4gYSBub2RlIHdpdGggYSBf
SElEIG9mIEVJU0FJRCAoUE5QMEMwMiksIGFuZAorICAgIHRoZSByZXNvdXJjZXMgaW4gdGhpcyBj
YXNlIHNob3VsZCBub3QgYmUgY2xhaW1lZCBpbiB0aGUgcm9vdCBQQ0kgYnVz4oCZcworICAgIF9D
UlMuICBUaGUgcmVzb3VyY2VzIGNhbiBvcHRpb25hbGx5IGJlIHJldHVybmVkIGluIEludDE1IEU4
MjAgb3IKKyAgICBFRklHZXRNZW1vcnlNYXAgYXMgcmVzZXJ2ZWQgbWVtb3J5IGJ1dCBtdXN0IGFs
d2F5cyBiZSByZXBvcnRlZCB0aHJvdWdoCisgICAgQUNQSSBhcyBhIG1vdGhlcmJvYXJkIHJlc291
cmNlLgorCitbN10gUENJIEV4cHJlc3MgMy4wLCBzZWMgNy4yLjI6CisgICAgRm9yIHN5c3RlbXMg
dGhhdCBhcmUgUEMtY29tcGF0aWJsZSwgb3IgdGhhdCBkbyBub3QgaW1wbGVtZW50IGEKKyAgICBw
cm9jZXNzb3ItYXJjaGl0ZWN0dXJlLXNwZWNpZmljIGZpcm13YXJlIGludGVyZmFjZSBzdGFuZGFy
ZCB0aGF0IGFsbG93cworICAgIGFjY2VzcyB0byB0aGUgQ29uZmlndXJhdGlvbiBTcGFjZSwgdGhl
IEVDQU0gaXMgcmVxdWlyZWQgYXMgZGVmaW5lZCBpbgorICAgIHRoaXMgc2VjdGlvbi4KKworWzhd
IFBDSSBGaXJtd2FyZSAzLjAsIHNlYyA0LjEuMjoKKyAgICBUaGUgTUNGRyB0YWJsZSBpcyBhbiBB
Q1BJIHRhYmxlIHRoYXQgaXMgdXNlZCB0byBjb21tdW5pY2F0ZSB0aGUgYmFzZQorICAgIGFkZHJl
c3NlcyBjb3JyZXNwb25kaW5nIHRvIHRoZSBub24taG90IHJlbW92YWJsZSBQQ0kgU2VnbWVudCBH
cm91cHMKKyAgICByYW5nZSB3aXRoaW4gYSBQQ0kgU2VnbWVudCBHcm91cCBhdmFpbGFibGUgdG8g
dGhlIG9wZXJhdGluZyBzeXN0ZW0gYXQKKyAgICBib290LiBUaGlzIGlzIHJlcXVpcmVkIGZvciB0
aGUgUEMtY29tcGF0aWJsZSBzeXN0ZW1zLgorCisgICAgVGhlIE1DRkcgdGFibGUgaXMgb25seSB1
c2VkIHRvIGNvbW11bmljYXRlIHRoZSBiYXNlIGFkZHJlc3NlcworICAgIGNvcnJlc3BvbmRpbmcg
dG8gdGhlIFBDSSBTZWdtZW50IEdyb3VwcyBhdmFpbGFibGUgdG8gdGhlIHN5c3RlbSBhdAorICAg
IGJvb3QuCisKK1s5XSBQQ0kgRmlybXdhcmUgMy4wLCBzZWMgNC4xLjM6CisgICAgVGhlIF9DQkEg
KE1lbW9yeSBtYXBwZWQgQ29uZmlndXJhdGlvbiBCYXNlIEFkZHJlc3MpIGNvbnRyb2wgbWV0aG9k
IGlzCisgICAgYW4gb3B0aW9uYWwgQUNQSSBvYmplY3QgdGhhdCByZXR1cm5zIHRoZSA2NC1iaXQg
bWVtb3J5IG1hcHBlZAorICAgIGNvbmZpZ3VyYXRpb24gYmFzZSBhZGRyZXNzIGZvciB0aGUgaG90
IHBsdWcgY2FwYWJsZSBob3N0IGJyaWRnZS4gVGhlCisgICAgYmFzZSBhZGRyZXNzIHJldHVybmVk
IGJ5IF9DQkEgaXMgcHJvY2Vzc29yLXJlbGF0aXZlIGFkZHJlc3MuIFRoZSBfQ0JBCisgICAgY29u
dHJvbCBtZXRob2QgZXZhbHVhdGVzIHRvIGFuIEludGVnZXIuCisKKyAgICBUaGlzIGNvbnRyb2wg
bWV0aG9kIGFwcGVhcnMgdW5kZXIgYSBob3N0IGJyaWRnZSBvYmplY3QuIFdoZW4gdGhlIF9DQkEK
KyAgICBtZXRob2QgYXBwZWFycyB1bmRlciBhbiBhY3RpdmUgaG9zdCBicmlkZ2Ugb2JqZWN0LCB0
aGUgb3BlcmF0aW5nIHN5c3RlbQorICAgIGV2YWx1YXRlcyB0aGlzIHN0cnVjdHVyZSB0byBpZGVu
dGlmeSB0aGUgbWVtb3J5IG1hcHBlZCBjb25maWd1cmF0aW9uCisgICAgYmFzZSBhZGRyZXNzIGNv
cnJlc3BvbmRpbmcgdG8gdGhlIFBDSSBTZWdtZW50IEdyb3VwIGZvciB0aGUgYnVzIG51bWJlcgor
ICAgIHJhbmdlIHNwZWNpZmllZCBpbiBfQ1JTIG1ldGhvZC4gQW4gQUNQSSBuYW1lIHNwYWNlIG9i
amVjdCB0aGF0IGNvbnRhaW5zCisgICAgdGhlIF9DQkEgbWV0aG9kIG11c3QgYWxzbyBjb250YWlu
IGEgY29ycmVzcG9uZGluZyBfU0VHIG1ldGhvZC4KCgpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51
eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5v
cmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2VybmVsCg==

[PATCH v2] PCI: Add information about describing PCI in ACPI

[Bjorn Helgaas]

Add a writeup about how PCI host bridges should be described in ACPI
using PNP0A03/PNP0A08 devices, PNP0C02 devices, and the MCFG table.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
 Documentation/PCI/00-INDEX      |    2 
 Documentation/PCI/acpi-info.txt |  180 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 182 insertions(+)
 create mode 100644 Documentation/PCI/acpi-info.txt

diff --git a/Documentation/PCI/00-INDEX b/Documentation/PCI/00-INDEX
index 147231f..0780280 100644
--- a/Documentation/PCI/00-INDEX
+++ b/Documentation/PCI/00-INDEX
@@ -1,5 +1,7 @@
 00-INDEX
 	- this file
+acpi-info.txt
+	- info on how PCI host bridges are represented in ACPI
 MSI-HOWTO.txt
 	- the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ.
 PCIEBUS-HOWTO.txt
diff --git a/Documentation/PCI/acpi-info.txt b/Documentation/PCI/acpi-info.txt
new file mode 100644
index 0000000..06b877f
--- /dev/null
+++ b/Documentation/PCI/acpi-info.txt
@@ -0,0 +1,180 @@
+	    ACPI considerations for PCI host bridges
+
+The basic requirement is that the ACPI namespace should describe
+*everything* that consumes address space unless there's another standard
+way for the OS to find it [1, 2]. ?For example, windows that are forwarded
+to PCI by a PCI host bridge should be described via ACPI devices, since the
+OS can't locate the host bridge by itself. ?PCI devices *below* the host
+bridge do not need to be described via ACPI, because the resources they
+consume are inside the host bridge windows, and the OS can discover them
+via the standard PCI enumeration mechanism (using config accesses to read
+and size the BARs).
+
+This ACPI resource description is done via _CRS objects of devices in the
+ACPI namespace [2]. ? The _CRS is like a generalized PCI BAR: the OS can
+read _CRS and figure out what resource is being consumed even if it doesn't
+have a driver for the device [3]. ?That's important because it means an old
+OS can work correctly even on a system with new devices unknown to the OS.
+The new devices won't do anything, but the OS can at least make sure no
+resources conflict with them.
+
+Static tables like MCFG, HPET, ECDT, etc., are *not* mechanisms for
+reserving address space!  The static tables are for things the OS needs to
+know early in boot, before it can parse the ACPI namespace.  If a new table
+is defined, an old OS needs to operate correctly even though it ignores the
+table.  _CRS allows that because it is generic and understood by the old
+OS; a static table does not.
+
+If the OS is expected to manage a non-discoverable device described via
+ACPI, that device will have a specific _HID/_CID that tells the OS what
+driver to bind to it, and the _CRS tells the OS and the driver where the
+device's registers are.
+
+PCI host bridges are PNP0A03 or PNP0A08 devices. ?Their _CRS should
+describe all the address space they consume. ?This includes all the windows
+they forward down to the PCI bus, as well as bridge registers that are not
+forwarded to PCI. ?The bridge registers include things like secondary/
+subordinate bus registers that determine the bus range below the bridge,
+window registers that describe the apertures, etc. ?These are all
+device-specific, non-architected things, so the only way a PNP0A03/PNP0A08
+driver can manage them is via _PRS/_CRS/_SRS, which contain the
+device-specific details. ?The bridge registers also include ECAM space,
+since it is consumed by the bridge.
+
+ACPI defines a Consumer/Producer bit to distinguish the bridge registers
+("Consumer") from the bridge apertures ("Producer") [4, 5], but early
+BIOSes didn't use that bit correctly.  The result is that the current ACPI
+spec defines Consumer/Producer only for the relatively new Extended Address
+Space descriptors; the bit should be ignored in the older QWord/DWord/Word
+Address Space descriptors.  Consequently, OSes have to assume all
+QWord/DWord/Word descriptors are windows.
+
+Prior to the addition of Extended Address Space descriptors, the failure of
+Consumer/Producer meant there was no way to describe bridge registers in
+the PNP0A03/PNP0A08 device itself.  The workaround was to describe the
+bridge registers (including ECAM space) in PNP0C02 catch-all devices [6].
+With the exception of ECAM, the bridge register space is device-specific
+anyway, so the generic PNP0A03/PNP0A08 driver (pci_root.c) has no need to
+know about it. ?
+
+New architectures should be able to use "Consumer" Extended Address Space
+descriptors in the PNP0A03 device for bridge registers, including ECAM,
+although a strict interpretation of [6] might prohibit this.  Old x86 and
+ia64 kernels assume all address space descriptors, including "Consumer"
+Extended Address Space ones, are windows, so it would not be safe to
+describe bridge registers this way on those architectures.
+
+PNP0C02 "motherboard" devices are basically a catch-all. ?There's no
+programming model for them other than "don't use these resources for
+anything else." ?So a PNP0C02 _CRS should claim any address space that is
+(1) not claimed by _CRS under any other device object in the ACPI namespace
+and (2) should not be assigned by the OS to something else.
+
+The PCIe spec requires the Enhanced Configuration Access Method (ECAM)
+unless there's a standard firmware interface for config access, e.g., the
+ia64 SAL interface [7].  A host bridge consumes ECAM memory address space
+and converts memory accesses into PCI configuration accesses.  The spec
+defines the ECAM address space layout and functionality; only the base of
+the address space is device-specific.  An ACPI OS learns the base address
+from either the static MCFG table or a _CBA method in the PNP0A03 device.
+
+The MCFG table must describe the ECAM space of non-hot pluggable host
+bridges [8].  Since MCFG is a static table and can't be updated by hotplug,
+a _CBA method in the PNP0A03 device describes the ECAM space of a
+hot-pluggable host bridge [9].  Note that for both MCFG and _CBA, the base
+address always corresponds to bus 0, even if the bus range below the bridge
+(which is reported via _CRS) doesn't start at 0.
+
+
+[1] ACPI 6.0, sec 6.1:
+    For any device that is on a non-enumerable type of bus (for example, an
+    ISA bus), OSPM enumerates the devices' identifier(s) and the ACPI
+    system firmware must supply an _HID object ... for each device to
+    enable OSPM to do that.
+
+[2] ACPI 6.0, sec 3.7:
+    The OS enumerates motherboard devices simply by reading through the
+    ACPI Namespace looking for devices with hardware IDs.
+
+    Each device enumerated by ACPI includes ACPI-defined objects in the
+    ACPI Namespace that report the hardware resources the device could
+    occupy [_PRS], an object that reports the resources that are currently
+    used by the device [_CRS], and objects for configuring those resources
+    [_SRS].  The information is used by the Plug and Play OS (OSPM) to
+    configure the devices.
+
+[3] ACPI 6.0, sec 6.2:
+    OSPM uses device configuration objects to configure hardware resources
+    for devices enumerated via ACPI.  Device configuration objects provide
+    information about current and possible resource requirements, the
+    relationship between shared resources, and methods for configuring
+    hardware resources.
+
+    When OSPM enumerates a device, it calls _PRS to determine the resource
+    requirements of the device.  It may also call _CRS to find the current
+    resource settings for the device.  Using this information, the Plug and
+    Play system determines what resources the device should consume and
+    sets those resources by calling the device?s _SRS control method.
+
+    In ACPI, devices can consume resources (for example, legacy keyboards),
+    provide resources (for example, a proprietary PCI bridge), or do both.
+    Unless otherwise specified, resources for a device are assumed to be
+    taken from the nearest matching resource above the device in the device
+    hierarchy.
+
+[4] ACPI 6.0, sec 6.4.3.5.1, 2, 3, 4:
+    QWord/DWord/Word Address Space Descriptor (.1, .2, .3)
+    General Flags: Bit [0] Ignored
+
+    Extended Address Space Descriptor (.4)
+    General Flags: Bit [0] Consumer/Producer:
+	1?This device consumes this resource
+	0?This device produces and consumes this resource
+
+[5] ACPI 6.0, sec 19.6.43:
+    ResourceUsage specifies whether the Memory range is consumed by
+    this device (ResourceConsumer) or passed on to child devices
+    (ResourceProducer).  If nothing is specified, then
+    ResourceConsumer is assumed.
+
+[6] PCI Firmware 3.0, sec 4.1.2:
+    If the operating system does not natively comprehend reserving the
+    MMCFG region, the MMCFG region must be reserved by firmware.  The
+    address range reported in the MCFG table or by _CBA method (see Section
+    4.1.3) must be reserved by declaring a motherboard resource.  For most
+    systems, the motherboard resource would appear at the root of the ACPI
+    namespace (under \_SB) in a node with a _HID of EISAID (PNP0C02), and
+    the resources in this case should not be claimed in the root PCI bus?s
+    _CRS.  The resources can optionally be returned in Int15 E820 or
+    EFIGetMemoryMap as reserved memory but must always be reported through
+    ACPI as a motherboard resource.
+
+[7] PCI Express 3.0, sec 7.2.2:
+    For systems that are PC-compatible, or that do not implement a
+    processor-architecture-specific firmware interface standard that allows
+    access to the Configuration Space, the ECAM is required as defined in
+    this section.
+
+[8] PCI Firmware 3.0, sec 4.1.2:
+    The MCFG table is an ACPI table that is used to communicate the base
+    addresses corresponding to the non-hot removable PCI Segment Groups
+    range within a PCI Segment Group available to the operating system at
+    boot. This is required for the PC-compatible systems.
+
+    The MCFG table is only used to communicate the base addresses
+    corresponding to the PCI Segment Groups available to the system at
+    boot.
+
+[9] PCI Firmware 3.0, sec 4.1.3:
+    The _CBA (Memory mapped Configuration Base Address) control method is
+    an optional ACPI object that returns the 64-bit memory mapped
+    configuration base address for the hot plug capable host bridge. The
+    base address returned by _CBA is processor-relative address. The _CBA
+    control method evaluates to an Integer.
+
+    This control method appears under a host bridge object. When the _CBA
+    method appears under an active host bridge object, the operating system
+    evaluates this structure to identify the memory mapped configuration
+    base address corresponding to the PCI Segment Group for the bus number
+    range specified in _CRS method. An ACPI name space object that contains
+    the _CBA method must also contain a corresponding _SEG method.

Re: [PATCH v2] PCI: Add information about describing PCI in ACPI

[Linus Torvalds]

Bjorn, this email was marked as spam, because:

  It has a from address in google.com but has failed google.com's
required tests for authentication

in particular, it looks like you used a non-google smtp server
(kernel.org) to send the email, so there is no DKIM hash (or perhaps
google just uses some other non-standard marker for "this actually
came from google"). So gmail marks it as spam because dmarc fails:

       dmarc=fail (p=REJECT dis=NONE) header.from=google.com

Just to let you know. If you use your google.com email, you do need to
go through the google smtp server.

This may or may not be new - I didn't go and look at old messages of
yours, but it is possible that google.com enabled dmarc/dkim recently.

             Linus

On Tue, Nov 29, 2016 at 1:39 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> Here's another stab at this writeup.  I'd appreciate any comments!

Re: [PATCH v2] PCI: Add information about describing PCI in ACPI

[Linus Torvalds]

Bjorn, this email was marked as spam, because:

  It has a from address in google.com but has failed google.com's
required tests for authentication

in particular, it looks like you used a non-google smtp server
(kernel.org) to send the email, so there is no DKIM hash (or perhaps
google just uses some other non-standard marker for "this actually
came from google"). So gmail marks it as spam because dmarc fails:

       dmarc=fail (p=REJECT dis=NONE) header.from=google.com

Just to let you know. If you use your google.com email, you do need to
go through the google smtp server.

This may or may not be new - I didn't go and look at old messages of
yours, but it is possible that google.com enabled dmarc/dkim recently.

             Linus

On Tue, Nov 29, 2016 at 1:39 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> Here's another stab at this writeup.  I'd appreciate any comments!

[PATCH v2] PCI: Add information about describing PCI in ACPI

[Linus Torvalds]

Bjorn, this email was marked as spam, because:

  It has a from address in google.com but has failed google.com's
required tests for authentication

in particular, it looks like you used a non-google smtp server
(kernel.org) to send the email, so there is no DKIM hash (or perhaps
google just uses some other non-standard marker for "this actually
came from google"). So gmail marks it as spam because dmarc fails:

       dmarc=fail (p=REJECT dis=NONE) header.from=google.com

Just to let you know. If you use your google.com email, you do need to
go through the google smtp server.

This may or may not be new - I didn't go and look at old messages of
yours, but it is possible that google.com enabled dmarc/dkim recently.

             Linus

On Tue, Nov 29, 2016 at 1:39 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> Here's another stab at this writeup.  I'd appreciate any comments!

Re: [PATCH v2] PCI: Add information about describing PCI in ACPI

[Bjorn Helgaas]

On Tue, Nov 29, 2016 at 03:39:11PM -0800, Linus Torvalds wrote:
> Bjorn, this email was marked as spam, because:
> 
>   It has a from address in google.com but has failed google.com's
> required tests for authentication
> 
> in particular, it looks like you used a non-google smtp server
> (kernel.org) to send the email, so there is no DKIM hash (or perhaps
> google just uses some other non-standard marker for "this actually
> came from google"). So gmail marks it as spam because dmarc fails:
> 
>        dmarc=fail (p=REJECT dis=NONE) header.from=google.com
> 
> Just to let you know. If you use your google.com email, you do need to
> go through the google smtp server.
> 
> This may or may not be new - I didn't go and look at old messages of
> yours, but it is possible that google.com enabled dmarc/dkim recently.

Argh, thanks for letting me know.  Looks like I've had this broken for a
long time, but I didn't notice.  I think I have it fixed so git will record
the author as bhelgaas@google.com, but git/stgit will send email from
helgaas@kernel.org via the kernel.org smtp server.

Re: [PATCH v2] PCI: Add information about describing PCI in ACPI

[Bjorn Helgaas]

On Tue, Nov 29, 2016 at 03:39:11PM -0800, Linus Torvalds wrote:
> Bjorn, this email was marked as spam, because:
> 
>   It has a from address in google.com but has failed google.com's
> required tests for authentication
> 
> in particular, it looks like you used a non-google smtp server
> (kernel.org) to send the email, so there is no DKIM hash (or perhaps
> google just uses some other non-standard marker for "this actually
> came from google"). So gmail marks it as spam because dmarc fails:
> 
>        dmarc=fail (p=REJECT dis=NONE) header.from=google.com
> 
> Just to let you know. If you use your google.com email, you do need to
> go through the google smtp server.
> 
> This may or may not be new - I didn't go and look at old messages of
> yours, but it is possible that google.com enabled dmarc/dkim recently.

Argh, thanks for letting me know.  Looks like I've had this broken for a
long time, but I didn't notice.  I think I have it fixed so git will record
the author as bhelgaas@google.com, but git/stgit will send email from
helgaas@kernel.org via the kernel.org smtp server.

Re: [PATCH v2] PCI: Add information about describing PCI in ACPI

[Bjorn Helgaas]

On Tue, Nov 29, 2016 at 03:39:11PM -0800, Linus Torvalds wrote:
> Bjorn, this email was marked as spam, because:
> 
>   It has a from address in google.com but has failed google.com's
> required tests for authentication
> 
> in particular, it looks like you used a non-google smtp server
> (kernel.org) to send the email, so there is no DKIM hash (or perhaps
> google just uses some other non-standard marker for "this actually
> came from google"). So gmail marks it as spam because dmarc fails:
> 
>        dmarc=fail (p=REJECT dis=NONE) header.from=google.com
> 
> Just to let you know. If you use your google.com email, you do need to
> go through the google smtp server.
> 
> This may or may not be new - I didn't go and look at old messages of
> yours, but it is possible that google.com enabled dmarc/dkim recently.

Argh, thanks for letting me know.  Looks like I've had this broken for a
long time, but I didn't notice.  I think I have it fixed so git will record
the author as bhelgaas@google.com, but git/stgit will send email from
helgaas@kernel.org via the kernel.org smtp server.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2] PCI: Add information about describing PCI in ACPI

[Bjorn Helgaas]

On Tue, Nov 29, 2016 at 03:39:11PM -0800, Linus Torvalds wrote:
> Bjorn, this email was marked as spam, because:
> 
>   It has a from address in google.com but has failed google.com's
> required tests for authentication
> 
> in particular, it looks like you used a non-google smtp server
> (kernel.org) to send the email, so there is no DKIM hash (or perhaps
> google just uses some other non-standard marker for "this actually
> came from google"). So gmail marks it as spam because dmarc fails:
> 
>        dmarc=fail (p=REJECT dis=NONE) header.from=google.com
> 
> Just to let you know. If you use your google.com email, you do need to
> go through the google smtp server.
> 
> This may or may not be new - I didn't go and look at old messages of
> yours, but it is possible that google.com enabled dmarc/dkim recently.

Argh, thanks for letting me know.  Looks like I've had this broken for a
long time, but I didn't notice.  I think I have it fixed so git will record
the author as bhelgaas at google.com, but git/stgit will send email from
helgaas at kernel.org via the kernel.org smtp server.

Re: [PATCH v2] PCI: Add information about describing PCI in ACPI

[Bjorn Helgaas]

On Tue, Nov 29, 2016 at 03:39:48PM -0600, Bjorn Helgaas wrote:
> Here's another stab at this writeup.  I'd appreciate any comments!
> 
> Changes from v1 to v2:
>   - Consumer/Producer is defined for Extended Address Space descriptors;
>     should be ignored for QWord/DWord/Word Address Space descriptors
>   - New arches may use Extended Address Space descriptors in PNP0A03 for
>     bridge registers, including ECAM (if the arch adds support for this)
>   - Add more details about MCFG and _CBA (Lv's suggestion)
>   - Incorporate Rafael's suggestions
> 
> ---
> 
> Bjorn Helgaas (1):
>       PCI: Add information about describing PCI in ACPI
> 
> 
>  Documentation/PCI/00-INDEX      |    2 
>  Documentation/PCI/acpi-info.txt |  180 +++++++++++++++++++++++++++++++++++++++
>  2 files changed, 182 insertions(+)
>  create mode 100644 Documentation/PCI/acpi-info.txt

It's very late in the cycle, but I'm considering trying to squeeze
this into v4.9 on the grounds that:

  - It's only a documentation change and can't break anything, and

  - Distributing it more widely may help the arm64 firmware ecosystem

But I don't want to disseminate misleading or incorrect information,
so if it needs clarification or wordsmithing, or even just maturation,
I'll wait until v4.10.

The Consumer/Producer stuff, in particular, doesn't seem 100% settled
yet.  Your thoughts, and especially your improvements, are welcome!

Bjorn

[PATCH v2] PCI: Add information about describing PCI in ACPI

[Bjorn Helgaas]

On Tue, Nov 29, 2016 at 03:39:48PM -0600, Bjorn Helgaas wrote:
> Here's another stab at this writeup.  I'd appreciate any comments!
> 
> Changes from v1 to v2:
>   - Consumer/Producer is defined for Extended Address Space descriptors;
>     should be ignored for QWord/DWord/Word Address Space descriptors
>   - New arches may use Extended Address Space descriptors in PNP0A03 for
>     bridge registers, including ECAM (if the arch adds support for this)
>   - Add more details about MCFG and _CBA (Lv's suggestion)
>   - Incorporate Rafael's suggestions
> 
> ---
> 
> Bjorn Helgaas (1):
>       PCI: Add information about describing PCI in ACPI
> 
> 
>  Documentation/PCI/00-INDEX      |    2 
>  Documentation/PCI/acpi-info.txt |  180 +++++++++++++++++++++++++++++++++++++++
>  2 files changed, 182 insertions(+)
>  create mode 100644 Documentation/PCI/acpi-info.txt

It's very late in the cycle, but I'm considering trying to squeeze
this into v4.9 on the grounds that:

  - It's only a documentation change and can't break anything, and

  - Distributing it more widely may help the arm64 firmware ecosystem

But I don't want to disseminate misleading or incorrect information,
so if it needs clarification or wordsmithing, or even just maturation,
I'll wait until v4.10.

The Consumer/Producer stuff, in particular, doesn't seem 100% settled
yet.  Your thoughts, and especially your improvements, are welcome!

Bjorn

Re: [PATCH v2] PCI: Add information about describing PCI in ACPI

[Rafael J. Wysocki]

On Thursday, December 01, 2016 04:36:04 PM Bjorn Helgaas wrote:
> On Tue, Nov 29, 2016 at 03:39:48PM -0600, Bjorn Helgaas wrote:
> > Here's another stab at this writeup.  I'd appreciate any comments!
> > 
> > Changes from v1 to v2:
> >   - Consumer/Producer is defined for Extended Address Space descriptors;
> >     should be ignored for QWord/DWord/Word Address Space descriptors
> >   - New arches may use Extended Address Space descriptors in PNP0A03 for
> >     bridge registers, including ECAM (if the arch adds support for this)
> >   - Add more details about MCFG and _CBA (Lv's suggestion)
> >   - Incorporate Rafael's suggestions
> > 
> > ---
> > 
> > Bjorn Helgaas (1):
> >       PCI: Add information about describing PCI in ACPI
> > 
> > 
> >  Documentation/PCI/00-INDEX      |    2 
> >  Documentation/PCI/acpi-info.txt |  180 +++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 182 insertions(+)
> >  create mode 100644 Documentation/PCI/acpi-info.txt
> 
> It's very late in the cycle, but I'm considering trying to squeeze
> this into v4.9 on the grounds that:
> 
>   - It's only a documentation change and can't break anything, and
> 
>   - Distributing it more widely may help the arm64 firmware ecosystem
> 
> But I don't want to disseminate misleading or incorrect information,
> so if it needs clarification or wordsmithing, or even just maturation,
> I'll wait until v4.10.
> 
> The Consumer/Producer stuff, in particular, doesn't seem 100% settled
> yet.  Your thoughts, and especially your improvements, are welcome!

Well, what's the drawback if it doesn't go into 4.9?

Thanks,
Rafael

[PATCH v2] PCI: Add information about describing PCI in ACPI

[Rafael J. Wysocki]

On Thursday, December 01, 2016 04:36:04 PM Bjorn Helgaas wrote:
> On Tue, Nov 29, 2016 at 03:39:48PM -0600, Bjorn Helgaas wrote:
> > Here's another stab at this writeup.  I'd appreciate any comments!
> > 
> > Changes from v1 to v2:
> >   - Consumer/Producer is defined for Extended Address Space descriptors;
> >     should be ignored for QWord/DWord/Word Address Space descriptors
> >   - New arches may use Extended Address Space descriptors in PNP0A03 for
> >     bridge registers, including ECAM (if the arch adds support for this)
> >   - Add more details about MCFG and _CBA (Lv's suggestion)
> >   - Incorporate Rafael's suggestions
> > 
> > ---
> > 
> > Bjorn Helgaas (1):
> >       PCI: Add information about describing PCI in ACPI
> > 
> > 
> >  Documentation/PCI/00-INDEX      |    2 
> >  Documentation/PCI/acpi-info.txt |  180 +++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 182 insertions(+)
> >  create mode 100644 Documentation/PCI/acpi-info.txt
> 
> It's very late in the cycle, but I'm considering trying to squeeze
> this into v4.9 on the grounds that:
> 
>   - It's only a documentation change and can't break anything, and
> 
>   - Distributing it more widely may help the arm64 firmware ecosystem
> 
> But I don't want to disseminate misleading or incorrect information,
> so if it needs clarification or wordsmithing, or even just maturation,
> I'll wait until v4.10.
> 
> The Consumer/Producer stuff, in particular, doesn't seem 100% settled
> yet.  Your thoughts, and especially your improvements, are welcome!

Well, what's the drawback if it doesn't go into 4.9?

Thanks,
Rafael

Re: [PATCH v2] PCI: Add information about describing PCI in ACPI

[Bjorn Helgaas]

On Thu, Dec 01, 2016 at 11:37:39PM +0100, Rafael J. Wysocki wrote:
> On Thursday, December 01, 2016 04:36:04 PM Bjorn Helgaas wrote:
> > On Tue, Nov 29, 2016 at 03:39:48PM -0600, Bjorn Helgaas wrote:
> > > Here's another stab at this writeup.  I'd appreciate any comments!
> > > 
> > > Changes from v1 to v2:
> > >   - Consumer/Producer is defined for Extended Address Space descriptors;
> > >     should be ignored for QWord/DWord/Word Address Space descriptors
> > >   - New arches may use Extended Address Space descriptors in PNP0A03 for
> > >     bridge registers, including ECAM (if the arch adds support for this)
> > >   - Add more details about MCFG and _CBA (Lv's suggestion)
> > >   - Incorporate Rafael's suggestions
> > > 
> > > ---
> > > 
> > > Bjorn Helgaas (1):
> > >       PCI: Add information about describing PCI in ACPI
> > > 
> > > 
> > >  Documentation/PCI/00-INDEX      |    2 
> > >  Documentation/PCI/acpi-info.txt |  180 +++++++++++++++++++++++++++++++++++++++
> > >  2 files changed, 182 insertions(+)
> > >  create mode 100644 Documentation/PCI/acpi-info.txt
> > 
> > It's very late in the cycle, but I'm considering trying to squeeze
> > this into v4.9 on the grounds that:
> > 
> >   - It's only a documentation change and can't break anything, and
> > 
> >   - Distributing it more widely may help the arm64 firmware ecosystem
> > 
> > But I don't want to disseminate misleading or incorrect information,
> > so if it needs clarification or wordsmithing, or even just maturation,
> > I'll wait until v4.10.
> > 
> > The Consumer/Producer stuff, in particular, doesn't seem 100% settled
> > yet.  Your thoughts, and especially your improvements, are welcome!
> 
> Well, what's the drawback if it doesn't go into 4.9?

Only that it's not as easily accessible.  ARM64 ACPI firmware is brand
new.  Neither the firmware nor the kernel developers, nor even the
hardware designers, have the benefit of all the x86/ia64 history, so I
wrote this to try to come to a common understanding of what Linux
expects.

The first generation of ARM64 hardware is already in the field, and it
has teething problems in hardware, firmware, and kernel.  For example,
the current MCFG quirk situation: the ECAM hardware doesn't work quite
per spec, the ACPI firmware doesn't describe the address space
completely, and we don't really have consensus on how the firmware
should communicate register space to the kernel.

We're hoping the second generation can fix some of these problems, and
I think this is the time to try to influence that.

Bjorn

Re: [PATCH v2] PCI: Add information about describing PCI in ACPI

[Bjorn Helgaas]

On Thu, Dec 01, 2016 at 11:37:39PM +0100, Rafael J. Wysocki wrote:
> On Thursday, December 01, 2016 04:36:04 PM Bjorn Helgaas wrote:
> > On Tue, Nov 29, 2016 at 03:39:48PM -0600, Bjorn Helgaas wrote:
> > > Here's another stab at this writeup.  I'd appreciate any comments!
> > > 
> > > Changes from v1 to v2:
> > >   - Consumer/Producer is defined for Extended Address Space descriptors;
> > >     should be ignored for QWord/DWord/Word Address Space descriptors
> > >   - New arches may use Extended Address Space descriptors in PNP0A03 for
> > >     bridge registers, including ECAM (if the arch adds support for this)
> > >   - Add more details about MCFG and _CBA (Lv's suggestion)
> > >   - Incorporate Rafael's suggestions
> > > 
> > > ---
> > > 
> > > Bjorn Helgaas (1):
> > >       PCI: Add information about describing PCI in ACPI
> > > 
> > > 
> > >  Documentation/PCI/00-INDEX      |    2 
> > >  Documentation/PCI/acpi-info.txt |  180 +++++++++++++++++++++++++++++++++++++++
> > >  2 files changed, 182 insertions(+)
> > >  create mode 100644 Documentation/PCI/acpi-info.txt
> > 
> > It's very late in the cycle, but I'm considering trying to squeeze
> > this into v4.9 on the grounds that:
> > 
> >   - It's only a documentation change and can't break anything, and
> > 
> >   - Distributing it more widely may help the arm64 firmware ecosystem
> > 
> > But I don't want to disseminate misleading or incorrect information,
> > so if it needs clarification or wordsmithing, or even just maturation,
> > I'll wait until v4.10.
> > 
> > The Consumer/Producer stuff, in particular, doesn't seem 100% settled
> > yet.  Your thoughts, and especially your improvements, are welcome!
> 
> Well, what's the drawback if it doesn't go into 4.9?

Only that it's not as easily accessible.  ARM64 ACPI firmware is brand
new.  Neither the firmware nor the kernel developers, nor even the
hardware designers, have the benefit of all the x86/ia64 history, so I
wrote this to try to come to a common understanding of what Linux
expects.

The first generation of ARM64 hardware is already in the field, and it
has teething problems in hardware, firmware, and kernel.  For example,
the current MCFG quirk situation: the ECAM hardware doesn't work quite
per spec, the ACPI firmware doesn't describe the address space
completely, and we don't really have consensus on how the firmware
should communicate register space to the kernel.

We're hoping the second generation can fix some of these problems, and
I think this is the time to try to influence that.

Bjorn

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2] PCI: Add information about describing PCI in ACPI

[Bjorn Helgaas]

On Thu, Dec 01, 2016 at 11:37:39PM +0100, Rafael J. Wysocki wrote:
> On Thursday, December 01, 2016 04:36:04 PM Bjorn Helgaas wrote:
> > On Tue, Nov 29, 2016 at 03:39:48PM -0600, Bjorn Helgaas wrote:
> > > Here's another stab at this writeup.  I'd appreciate any comments!
> > > 
> > > Changes from v1 to v2:
> > >   - Consumer/Producer is defined for Extended Address Space descriptors;
> > >     should be ignored for QWord/DWord/Word Address Space descriptors
> > >   - New arches may use Extended Address Space descriptors in PNP0A03 for
> > >     bridge registers, including ECAM (if the arch adds support for this)
> > >   - Add more details about MCFG and _CBA (Lv's suggestion)
> > >   - Incorporate Rafael's suggestions
> > > 
> > > ---
> > > 
> > > Bjorn Helgaas (1):
> > >       PCI: Add information about describing PCI in ACPI
> > > 
> > > 
> > >  Documentation/PCI/00-INDEX      |    2 
> > >  Documentation/PCI/acpi-info.txt |  180 +++++++++++++++++++++++++++++++++++++++
> > >  2 files changed, 182 insertions(+)
> > >  create mode 100644 Documentation/PCI/acpi-info.txt
> > 
> > It's very late in the cycle, but I'm considering trying to squeeze
> > this into v4.9 on the grounds that:
> > 
> >   - It's only a documentation change and can't break anything, and
> > 
> >   - Distributing it more widely may help the arm64 firmware ecosystem
> > 
> > But I don't want to disseminate misleading or incorrect information,
> > so if it needs clarification or wordsmithing, or even just maturation,
> > I'll wait until v4.10.
> > 
> > The Consumer/Producer stuff, in particular, doesn't seem 100% settled
> > yet.  Your thoughts, and especially your improvements, are welcome!
> 
> Well, what's the drawback if it doesn't go into 4.9?

Only that it's not as easily accessible.  ARM64 ACPI firmware is brand
new.  Neither the firmware nor the kernel developers, nor even the
hardware designers, have the benefit of all the x86/ia64 history, so I
wrote this to try to come to a common understanding of what Linux
expects.

The first generation of ARM64 hardware is already in the field, and it
has teething problems in hardware, firmware, and kernel.  For example,
the current MCFG quirk situation: the ECAM hardware doesn't work quite
per spec, the ACPI firmware doesn't describe the address space
completely, and we don't really have consensus on how the firmware
should communicate register space to the kernel.

We're hoping the second generation can fix some of these problems, and
I think this is the time to try to influence that.

Bjorn

Re: [PATCH v2] PCI: Add information about describing PCI in ACPI

[Rafael J. Wysocki]

On Fri, Dec 2, 2016 at 12:27 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Thu, Dec 01, 2016 at 11:37:39PM +0100, Rafael J. Wysocki wrote:
>> On Thursday, December 01, 2016 04:36:04 PM Bjorn Helgaas wrote:
>> > On Tue, Nov 29, 2016 at 03:39:48PM -0600, Bjorn Helgaas wrote:
>> > > Here's another stab at this writeup.  I'd appreciate any comments!
>> > >
>> > > Changes from v1 to v2:
>> > >   - Consumer/Producer is defined for Extended Address Space descriptors;
>> > >     should be ignored for QWord/DWord/Word Address Space descriptors
>> > >   - New arches may use Extended Address Space descriptors in PNP0A03 for
>> > >     bridge registers, including ECAM (if the arch adds support for this)
>> > >   - Add more details about MCFG and _CBA (Lv's suggestion)
>> > >   - Incorporate Rafael's suggestions
>> > >
>> > > ---
>> > >
>> > > Bjorn Helgaas (1):
>> > >       PCI: Add information about describing PCI in ACPI
>> > >
>> > >
>> > >  Documentation/PCI/00-INDEX      |    2
>> > >  Documentation/PCI/acpi-info.txt |  180 +++++++++++++++++++++++++++++++++++++++
>> > >  2 files changed, 182 insertions(+)
>> > >  create mode 100644 Documentation/PCI/acpi-info.txt
>> >
>> > It's very late in the cycle, but I'm considering trying to squeeze
>> > this into v4.9 on the grounds that:
>> >
>> >   - It's only a documentation change and can't break anything, and
>> >
>> >   - Distributing it more widely may help the arm64 firmware ecosystem
>> >
>> > But I don't want to disseminate misleading or incorrect information,
>> > so if it needs clarification or wordsmithing, or even just maturation,
>> > I'll wait until v4.10.
>> >
>> > The Consumer/Producer stuff, in particular, doesn't seem 100% settled
>> > yet.  Your thoughts, and especially your improvements, are welcome!
>>
>> Well, what's the drawback if it doesn't go into 4.9?
>
> Only that it's not as easily accessible.  ARM64 ACPI firmware is brand
> new.  Neither the firmware nor the kernel developers, nor even the
> hardware designers, have the benefit of all the x86/ia64 history, so I
> wrote this to try to come to a common understanding of what Linux
> expects.
>
> The first generation of ARM64 hardware is already in the field, and it
> has teething problems in hardware, firmware, and kernel.  For example,
> the current MCFG quirk situation: the ECAM hardware doesn't work quite
> per spec, the ACPI firmware doesn't describe the address space
> completely, and we don't really have consensus on how the firmware
> should communicate register space to the kernel.
>
> We're hoping the second generation can fix some of these problems, and
> I think this is the time to try to influence that.

Well, I would be super-careful if I were you, then. :-)

I'm not sure if squeezing it into 4.9.0 buys you anything here.  If
you get it into 4.10-rc, you can request -stable to pick it up (at
least in principle) and then it will show up in 4.9.y at one point
which should suffice I suppose?

Thanks,
Rafael

Re: [PATCH v2] PCI: Add information about describing PCI in ACPI

[Rafael J. Wysocki]

On Fri, Dec 2, 2016 at 12:27 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Thu, Dec 01, 2016 at 11:37:39PM +0100, Rafael J. Wysocki wrote:
>> On Thursday, December 01, 2016 04:36:04 PM Bjorn Helgaas wrote:
>> > On Tue, Nov 29, 2016 at 03:39:48PM -0600, Bjorn Helgaas wrote:
>> > > Here's another stab at this writeup.  I'd appreciate any comments!
>> > >
>> > > Changes from v1 to v2:
>> > >   - Consumer/Producer is defined for Extended Address Space descriptors;
>> > >     should be ignored for QWord/DWord/Word Address Space descriptors
>> > >   - New arches may use Extended Address Space descriptors in PNP0A03 for
>> > >     bridge registers, including ECAM (if the arch adds support for this)
>> > >   - Add more details about MCFG and _CBA (Lv's suggestion)
>> > >   - Incorporate Rafael's suggestions
>> > >
>> > > ---
>> > >
>> > > Bjorn Helgaas (1):
>> > >       PCI: Add information about describing PCI in ACPI
>> > >
>> > >
>> > >  Documentation/PCI/00-INDEX      |    2
>> > >  Documentation/PCI/acpi-info.txt |  180 +++++++++++++++++++++++++++++++++++++++
>> > >  2 files changed, 182 insertions(+)
>> > >  create mode 100644 Documentation/PCI/acpi-info.txt
>> >
>> > It's very late in the cycle, but I'm considering trying to squeeze
>> > this into v4.9 on the grounds that:
>> >
>> >   - It's only a documentation change and can't break anything, and
>> >
>> >   - Distributing it more widely may help the arm64 firmware ecosystem
>> >
>> > But I don't want to disseminate misleading or incorrect information,
>> > so if it needs clarification or wordsmithing, or even just maturation,
>> > I'll wait until v4.10.
>> >
>> > The Consumer/Producer stuff, in particular, doesn't seem 100% settled
>> > yet.  Your thoughts, and especially your improvements, are welcome!
>>
>> Well, what's the drawback if it doesn't go into 4.9?
>
> Only that it's not as easily accessible.  ARM64 ACPI firmware is brand
> new.  Neither the firmware nor the kernel developers, nor even the
> hardware designers, have the benefit of all the x86/ia64 history, so I
> wrote this to try to come to a common understanding of what Linux
> expects.
>
> The first generation of ARM64 hardware is already in the field, and it
> has teething problems in hardware, firmware, and kernel.  For example,
> the current MCFG quirk situation: the ECAM hardware doesn't work quite
> per spec, the ACPI firmware doesn't describe the address space
> completely, and we don't really have consensus on how the firmware
> should communicate register space to the kernel.
>
> We're hoping the second generation can fix some of these problems, and
> I think this is the time to try to influence that.

Well, I would be super-careful if I were you, then. :-)

I'm not sure if squeezing it into 4.9.0 buys you anything here.  If
you get it into 4.10-rc, you can request -stable to pick it up (at
least in principle) and then it will show up in 4.9.y at one point
which should suffice I suppose?

Thanks,
Rafael

[PATCH v2] PCI: Add information about describing PCI in ACPI

[Rafael J. Wysocki]

On Fri, Dec 2, 2016 at 12:27 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Thu, Dec 01, 2016 at 11:37:39PM +0100, Rafael J. Wysocki wrote:
>> On Thursday, December 01, 2016 04:36:04 PM Bjorn Helgaas wrote:
>> > On Tue, Nov 29, 2016 at 03:39:48PM -0600, Bjorn Helgaas wrote:
>> > > Here's another stab at this writeup.  I'd appreciate any comments!
>> > >
>> > > Changes from v1 to v2:
>> > >   - Consumer/Producer is defined for Extended Address Space descriptors;
>> > >     should be ignored for QWord/DWord/Word Address Space descriptors
>> > >   - New arches may use Extended Address Space descriptors in PNP0A03 for
>> > >     bridge registers, including ECAM (if the arch adds support for this)
>> > >   - Add more details about MCFG and _CBA (Lv's suggestion)
>> > >   - Incorporate Rafael's suggestions
>> > >
>> > > ---
>> > >
>> > > Bjorn Helgaas (1):
>> > >       PCI: Add information about describing PCI in ACPI
>> > >
>> > >
>> > >  Documentation/PCI/00-INDEX      |    2
>> > >  Documentation/PCI/acpi-info.txt |  180 +++++++++++++++++++++++++++++++++++++++
>> > >  2 files changed, 182 insertions(+)
>> > >  create mode 100644 Documentation/PCI/acpi-info.txt
>> >
>> > It's very late in the cycle, but I'm considering trying to squeeze
>> > this into v4.9 on the grounds that:
>> >
>> >   - It's only a documentation change and can't break anything, and
>> >
>> >   - Distributing it more widely may help the arm64 firmware ecosystem
>> >
>> > But I don't want to disseminate misleading or incorrect information,
>> > so if it needs clarification or wordsmithing, or even just maturation,
>> > I'll wait until v4.10.
>> >
>> > The Consumer/Producer stuff, in particular, doesn't seem 100% settled
>> > yet.  Your thoughts, and especially your improvements, are welcome!
>>
>> Well, what's the drawback if it doesn't go into 4.9?
>
> Only that it's not as easily accessible.  ARM64 ACPI firmware is brand
> new.  Neither the firmware nor the kernel developers, nor even the
> hardware designers, have the benefit of all the x86/ia64 history, so I
> wrote this to try to come to a common understanding of what Linux
> expects.
>
> The first generation of ARM64 hardware is already in the field, and it
> has teething problems in hardware, firmware, and kernel.  For example,
> the current MCFG quirk situation: the ECAM hardware doesn't work quite
> per spec, the ACPI firmware doesn't describe the address space
> completely, and we don't really have consensus on how the firmware
> should communicate register space to the kernel.
>
> We're hoping the second generation can fix some of these problems, and
> I think this is the time to try to influence that.

Well, I would be super-careful if I were you, then. :-)

I'm not sure if squeezing it into 4.9.0 buys you anything here.  If
you get it into 4.10-rc, you can request -stable to pick it up (at
least in principle) and then it will show up in 4.9.y at one point
which should suffice I suppose?

Thanks,
Rafael

Re: [PATCH v2] PCI: Add information about describing PCI in ACPI

[Bjorn Helgaas]

On Fri, Dec 02, 2016 at 01:28:50AM +0100, Rafael J. Wysocki wrote:
> On Fri, Dec 2, 2016 at 12:27 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Thu, Dec 01, 2016 at 11:37:39PM +0100, Rafael J. Wysocki wrote:
> >> On Thursday, December 01, 2016 04:36:04 PM Bjorn Helgaas wrote:
> >> > On Tue, Nov 29, 2016 at 03:39:48PM -0600, Bjorn Helgaas wrote:
> >> > > Here's another stab at this writeup.  I'd appreciate any comments!
> >> > >
> >> > > Changes from v1 to v2:
> >> > >   - Consumer/Producer is defined for Extended Address Space descriptors;
> >> > >     should be ignored for QWord/DWord/Word Address Space descriptors
> >> > >   - New arches may use Extended Address Space descriptors in PNP0A03 for
> >> > >     bridge registers, including ECAM (if the arch adds support for this)
> >> > >   - Add more details about MCFG and _CBA (Lv's suggestion)
> >> > >   - Incorporate Rafael's suggestions
> >> > >
> >> > > ---
> >> > >
> >> > > Bjorn Helgaas (1):
> >> > >       PCI: Add information about describing PCI in ACPI
> >> > >
> >> > >
> >> > >  Documentation/PCI/00-INDEX      |    2
> >> > >  Documentation/PCI/acpi-info.txt |  180 +++++++++++++++++++++++++++++++++++++++
> >> > >  2 files changed, 182 insertions(+)
> >> > >  create mode 100644 Documentation/PCI/acpi-info.txt
> >> >
> >> > It's very late in the cycle, but I'm considering trying to squeeze
> >> > this into v4.9 on the grounds that:
> >> >
> >> >   - It's only a documentation change and can't break anything, and
> >> >
> >> >   - Distributing it more widely may help the arm64 firmware ecosystem
> >> >
> >> > But I don't want to disseminate misleading or incorrect information,
> >> > so if it needs clarification or wordsmithing, or even just maturation,
> >> > I'll wait until v4.10.
> >> >
> >> > The Consumer/Producer stuff, in particular, doesn't seem 100% settled
> >> > yet.  Your thoughts, and especially your improvements, are welcome!
> >>
> >> Well, what's the drawback if it doesn't go into 4.9?
> >
> > Only that it's not as easily accessible.  ARM64 ACPI firmware is brand
> > new.  Neither the firmware nor the kernel developers, nor even the
> > hardware designers, have the benefit of all the x86/ia64 history, so I
> > wrote this to try to come to a common understanding of what Linux
> > expects.
> >
> > The first generation of ARM64 hardware is already in the field, and it
> > has teething problems in hardware, firmware, and kernel.  For example,
> > the current MCFG quirk situation: the ECAM hardware doesn't work quite
> > per spec, the ACPI firmware doesn't describe the address space
> > completely, and we don't really have consensus on how the firmware
> > should communicate register space to the kernel.
> >
> > We're hoping the second generation can fix some of these problems, and
> > I think this is the time to try to influence that.
> 
> Well, I would be super-careful if I were you, then. :-)
> 
> I'm not sure if squeezing it into 4.9.0 buys you anything here.  If
> you get it into 4.10-rc, you can request -stable to pick it up (at
> least in principle) and then it will show up in 4.9.y at one point
> which should suffice I suppose?

You're right, there's no real hurry, and the rate of change is a good
indication that we need to let things settle out for a while.

Re: [PATCH v2] PCI: Add information about describing PCI in ACPI

[Bjorn Helgaas]

On Fri, Dec 02, 2016 at 01:28:50AM +0100, Rafael J. Wysocki wrote:
> On Fri, Dec 2, 2016 at 12:27 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Thu, Dec 01, 2016 at 11:37:39PM +0100, Rafael J. Wysocki wrote:
> >> On Thursday, December 01, 2016 04:36:04 PM Bjorn Helgaas wrote:
> >> > On Tue, Nov 29, 2016 at 03:39:48PM -0600, Bjorn Helgaas wrote:
> >> > > Here's another stab at this writeup.  I'd appreciate any comments!
> >> > >
> >> > > Changes from v1 to v2:
> >> > >   - Consumer/Producer is defined for Extended Address Space descriptors;
> >> > >     should be ignored for QWord/DWord/Word Address Space descriptors
> >> > >   - New arches may use Extended Address Space descriptors in PNP0A03 for
> >> > >     bridge registers, including ECAM (if the arch adds support for this)
> >> > >   - Add more details about MCFG and _CBA (Lv's suggestion)
> >> > >   - Incorporate Rafael's suggestions
> >> > >
> >> > > ---
> >> > >
> >> > > Bjorn Helgaas (1):
> >> > >       PCI: Add information about describing PCI in ACPI
> >> > >
> >> > >
> >> > >  Documentation/PCI/00-INDEX      |    2
> >> > >  Documentation/PCI/acpi-info.txt |  180 +++++++++++++++++++++++++++++++++++++++
> >> > >  2 files changed, 182 insertions(+)
> >> > >  create mode 100644 Documentation/PCI/acpi-info.txt
> >> >
> >> > It's very late in the cycle, but I'm considering trying to squeeze
> >> > this into v4.9 on the grounds that:
> >> >
> >> >   - It's only a documentation change and can't break anything, and
> >> >
> >> >   - Distributing it more widely may help the arm64 firmware ecosystem
> >> >
> >> > But I don't want to disseminate misleading or incorrect information,
> >> > so if it needs clarification or wordsmithing, or even just maturation,
> >> > I'll wait until v4.10.
> >> >
> >> > The Consumer/Producer stuff, in particular, doesn't seem 100% settled
> >> > yet.  Your thoughts, and especially your improvements, are welcome!
> >>
> >> Well, what's the drawback if it doesn't go into 4.9?
> >
> > Only that it's not as easily accessible.  ARM64 ACPI firmware is brand
> > new.  Neither the firmware nor the kernel developers, nor even the
> > hardware designers, have the benefit of all the x86/ia64 history, so I
> > wrote this to try to come to a common understanding of what Linux
> > expects.
> >
> > The first generation of ARM64 hardware is already in the field, and it
> > has teething problems in hardware, firmware, and kernel.  For example,
> > the current MCFG quirk situation: the ECAM hardware doesn't work quite
> > per spec, the ACPI firmware doesn't describe the address space
> > completely, and we don't really have consensus on how the firmware
> > should communicate register space to the kernel.
> >
> > We're hoping the second generation can fix some of these problems, and
> > I think this is the time to try to influence that.
> 
> Well, I would be super-careful if I were you, then. :-)
> 
> I'm not sure if squeezing it into 4.9.0 buys you anything here.  If
> you get it into 4.10-rc, you can request -stable to pick it up (at
> least in principle) and then it will show up in 4.9.y at one point
> which should suffice I suppose?

You're right, there's no real hurry, and the rate of change is a good
indication that we need to let things settle out for a while.

Re: [PATCH v2] PCI: Add information about describing PCI in ACPI

[Bjorn Helgaas]

On Fri, Dec 02, 2016 at 01:28:50AM +0100, Rafael J. Wysocki wrote:
> On Fri, Dec 2, 2016 at 12:27 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Thu, Dec 01, 2016 at 11:37:39PM +0100, Rafael J. Wysocki wrote:
> >> On Thursday, December 01, 2016 04:36:04 PM Bjorn Helgaas wrote:
> >> > On Tue, Nov 29, 2016 at 03:39:48PM -0600, Bjorn Helgaas wrote:
> >> > > Here's another stab at this writeup.  I'd appreciate any comments!
> >> > >
> >> > > Changes from v1 to v2:
> >> > >   - Consumer/Producer is defined for Extended Address Space descriptors;
> >> > >     should be ignored for QWord/DWord/Word Address Space descriptors
> >> > >   - New arches may use Extended Address Space descriptors in PNP0A03 for
> >> > >     bridge registers, including ECAM (if the arch adds support for this)
> >> > >   - Add more details about MCFG and _CBA (Lv's suggestion)
> >> > >   - Incorporate Rafael's suggestions
> >> > >
> >> > > ---
> >> > >
> >> > > Bjorn Helgaas (1):
> >> > >       PCI: Add information about describing PCI in ACPI
> >> > >
> >> > >
> >> > >  Documentation/PCI/00-INDEX      |    2
> >> > >  Documentation/PCI/acpi-info.txt |  180 +++++++++++++++++++++++++++++++++++++++
> >> > >  2 files changed, 182 insertions(+)
> >> > >  create mode 100644 Documentation/PCI/acpi-info.txt
> >> >
> >> > It's very late in the cycle, but I'm considering trying to squeeze
> >> > this into v4.9 on the grounds that:
> >> >
> >> >   - It's only a documentation change and can't break anything, and
> >> >
> >> >   - Distributing it more widely may help the arm64 firmware ecosystem
> >> >
> >> > But I don't want to disseminate misleading or incorrect information,
> >> > so if it needs clarification or wordsmithing, or even just maturation,
> >> > I'll wait until v4.10.
> >> >
> >> > The Consumer/Producer stuff, in particular, doesn't seem 100% settled
> >> > yet.  Your thoughts, and especially your improvements, are welcome!
> >>
> >> Well, what's the drawback if it doesn't go into 4.9?
> >
> > Only that it's not as easily accessible.  ARM64 ACPI firmware is brand
> > new.  Neither the firmware nor the kernel developers, nor even the
> > hardware designers, have the benefit of all the x86/ia64 history, so I
> > wrote this to try to come to a common understanding of what Linux
> > expects.
> >
> > The first generation of ARM64 hardware is already in the field, and it
> > has teething problems in hardware, firmware, and kernel.  For example,
> > the current MCFG quirk situation: the ECAM hardware doesn't work quite
> > per spec, the ACPI firmware doesn't describe the address space
> > completely, and we don't really have consensus on how the firmware
> > should communicate register space to the kernel.
> >
> > We're hoping the second generation can fix some of these problems, and
> > I think this is the time to try to influence that.
> 
> Well, I would be super-careful if I were you, then. :-)
> 
> I'm not sure if squeezing it into 4.9.0 buys you anything here.  If
> you get it into 4.10-rc, you can request -stable to pick it up (at
> least in principle) and then it will show up in 4.9.y at one point
> which should suffice I suppose?

You're right, there's no real hurry, and the rate of change is a good
indication that we need to let things settle out for a while.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2] PCI: Add information about describing PCI in ACPI

[Bjorn Helgaas]

On Fri, Dec 02, 2016 at 01:28:50AM +0100, Rafael J. Wysocki wrote:
> On Fri, Dec 2, 2016 at 12:27 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Thu, Dec 01, 2016 at 11:37:39PM +0100, Rafael J. Wysocki wrote:
> >> On Thursday, December 01, 2016 04:36:04 PM Bjorn Helgaas wrote:
> >> > On Tue, Nov 29, 2016 at 03:39:48PM -0600, Bjorn Helgaas wrote:
> >> > > Here's another stab at this writeup.  I'd appreciate any comments!
> >> > >
> >> > > Changes from v1 to v2:
> >> > >   - Consumer/Producer is defined for Extended Address Space descriptors;
> >> > >     should be ignored for QWord/DWord/Word Address Space descriptors
> >> > >   - New arches may use Extended Address Space descriptors in PNP0A03 for
> >> > >     bridge registers, including ECAM (if the arch adds support for this)
> >> > >   - Add more details about MCFG and _CBA (Lv's suggestion)
> >> > >   - Incorporate Rafael's suggestions
> >> > >
> >> > > ---
> >> > >
> >> > > Bjorn Helgaas (1):
> >> > >       PCI: Add information about describing PCI in ACPI
> >> > >
> >> > >
> >> > >  Documentation/PCI/00-INDEX      |    2
> >> > >  Documentation/PCI/acpi-info.txt |  180 +++++++++++++++++++++++++++++++++++++++
> >> > >  2 files changed, 182 insertions(+)
> >> > >  create mode 100644 Documentation/PCI/acpi-info.txt
> >> >
> >> > It's very late in the cycle, but I'm considering trying to squeeze
> >> > this into v4.9 on the grounds that:
> >> >
> >> >   - It's only a documentation change and can't break anything, and
> >> >
> >> >   - Distributing it more widely may help the arm64 firmware ecosystem
> >> >
> >> > But I don't want to disseminate misleading or incorrect information,
> >> > so if it needs clarification or wordsmithing, or even just maturation,
> >> > I'll wait until v4.10.
> >> >
> >> > The Consumer/Producer stuff, in particular, doesn't seem 100% settled
> >> > yet.  Your thoughts, and especially your improvements, are welcome!
> >>
> >> Well, what's the drawback if it doesn't go into 4.9?
> >
> > Only that it's not as easily accessible.  ARM64 ACPI firmware is brand
> > new.  Neither the firmware nor the kernel developers, nor even the
> > hardware designers, have the benefit of all the x86/ia64 history, so I
> > wrote this to try to come to a common understanding of what Linux
> > expects.
> >
> > The first generation of ARM64 hardware is already in the field, and it
> > has teething problems in hardware, firmware, and kernel.  For example,
> > the current MCFG quirk situation: the ECAM hardware doesn't work quite
> > per spec, the ACPI firmware doesn't describe the address space
> > completely, and we don't really have consensus on how the firmware
> > should communicate register space to the kernel.
> >
> > We're hoping the second generation can fix some of these problems, and
> > I think this is the time to try to influence that.
> 
> Well, I would be super-careful if I were you, then. :-)
> 
> I'm not sure if squeezing it into 4.9.0 buys you anything here.  If
> you get it into 4.10-rc, you can request -stable to pick it up (at
> least in principle) and then it will show up in 4.9.y at one point
> which should suffice I suppose?

You're right, there's no real hurry, and the rate of change is a good
indication that we need to let things settle out for a while.

Re: [PATCH v2] PCI: Add information about describing PCI in ACPI

[Jon Masters]

On 11/29/2016 04:39 PM, Bjorn Helgaas wrote:

> +New architectures should be able to use "Consumer" Extended Address Space
> +descriptors in the PNP0A03 device for bridge registers, including ECAM,
> +although a strict interpretation of [6] might prohibit this.  Old x86 and
> +ia64 kernels assume all address space descriptors, including "Consumer"
> +Extended Address Space ones, are windows, so it would not be safe to
> +describe bridge registers this way on those architectures.

<snip>

> +[6] PCI Firmware 3.0, sec 4.1.2:

<snip>

Thanks for the revised writeup, Bjorn. It's great. I'm trying to get the
above clarified explicitly in terms of the spec, and in terms of what
other Operating Systems would like to see as general preference.

To your point about second generation ARM (server) systems: we're actually
on generation 3+ now and finally getting to the point where people are
listening. A great many times over the past few years, people have had
to be sat on until they did what was needed. Fortunately, we are going
to finally have upstream kernels (and distros based upon them) that
boot out of the box on compliant hardware and will be able to point
people at the usual "upstream first" messaging we've been pushing.

I had originally fallen for the SoC koolaid that PCIe was not essential,
and was convinced fairly early that this was nonsense. But it has taken
a few years for everyone else to get onto that bandwagon. First you give
them exactly what they know and love (a 1-2 socket Xeon class machine
with lots of PCIe lanes), then you go and fix the design to give them
what they actually need (which logically enumerates as PCIe but isn't) ;)

Jon.

Re: [PATCH v2] PCI: Add information about describing PCI in ACPI

[Jon Masters]

On 11/29/2016 04:39 PM, Bjorn Helgaas wrote:

> +New architectures should be able to use "Consumer" Extended Address Space
> +descriptors in the PNP0A03 device for bridge registers, including ECAM,
> +although a strict interpretation of [6] might prohibit this.  Old x86 and
> +ia64 kernels assume all address space descriptors, including "Consumer"
> +Extended Address Space ones, are windows, so it would not be safe to
> +describe bridge registers this way on those architectures.

<snip>

> +[6] PCI Firmware 3.0, sec 4.1.2:

<snip>

Thanks for the revised writeup, Bjorn. It's great. I'm trying to get the
above clarified explicitly in terms of the spec, and in terms of what
other Operating Systems would like to see as general preference.

To your point about second generation ARM (server) systems: we're actually
on generation 3+ now and finally getting to the point where people are
listening. A great many times over the past few years, people have had
to be sat on until they did what was needed. Fortunately, we are going
to finally have upstream kernels (and distros based upon them) that
boot out of the box on compliant hardware and will be able to point
people at the usual "upstream first" messaging we've been pushing.

I had originally fallen for the SoC koolaid that PCIe was not essential,
and was convinced fairly early that this was nonsense. But it has taken
a few years for everyone else to get onto that bandwagon. First you give
them exactly what they know and love (a 1-2 socket Xeon class machine
with lots of PCIe lanes), then you go and fix the design to give them
what they actually need (which logically enumerates as PCIe but isn't) ;)

Jon.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2] PCI: Add information about describing PCI in ACPI

[Jon Masters]

On 11/29/2016 04:39 PM, Bjorn Helgaas wrote:

> +New architectures should be able to use "Consumer" Extended Address Space
> +descriptors in the PNP0A03 device for bridge registers, including ECAM,
> +although a strict interpretation of [6] might prohibit this.  Old x86 and
> +ia64 kernels assume all address space descriptors, including "Consumer"
> +Extended Address Space ones, are windows, so it would not be safe to
> +describe bridge registers this way on those architectures.

<snip>

> +[6] PCI Firmware 3.0, sec 4.1.2:

<snip>

Thanks for the revised writeup, Bjorn. It's great. I'm trying to get the
above clarified explicitly in terms of the spec, and in terms of what
other Operating Systems would like to see as general preference.

To your point about second generation ARM (server) systems: we're actually
on generation 3+ now and finally getting to the point where people are
listening. A great many times over the past few years, people have had
to be sat on until they did what was needed. Fortunately, we are going
to finally have upstream kernels (and distros based upon them) that
boot out of the box on compliant hardware and will be able to point
people at the usual "upstream first" messaging we've been pushing.

I had originally fallen for the SoC koolaid that PCIe was not essential,
and was convinced fairly early that this was nonsense. But it has taken
a few years for everyone else to get onto that bandwagon. First you give
them exactly what they know and love (a 1-2 socket Xeon class machine
with lots of PCIe lanes), then you go and fix the design to give them
what they actually need (which logically enumerates as PCIe but isn't) ;)

Jon.

Re: [PATCH v2] PCI: Add information about describing PCI in ACPI

[Bjorn Helgaas]

On Tue, Dec 13, 2016 at 04:09:39AM -0500, Jon Masters wrote:
> On 11/29/2016 04:39 PM, Bjorn Helgaas wrote:
> 
> > +New architectures should be able to use "Consumer" Extended Address Space
> > +descriptors in the PNP0A03 device for bridge registers, including ECAM,
> > +although a strict interpretation of [6] might prohibit this.  Old x86 and
> > +ia64 kernels assume all address space descriptors, including "Consumer"
> > +Extended Address Space ones, are windows, so it would not be safe to
> > +describe bridge registers this way on those architectures.
> 
> <snip>
> 
> > +[6] PCI Firmware 3.0, sec 4.1.2:
> 
> <snip>
> 
> Thanks for the revised writeup, Bjorn. It's great. I'm trying to get the
> above clarified explicitly in terms of the spec, and in terms of what
> other Operating Systems would like to see as general preference.

Any feedback on this?  I'd like to post a revised version soon for v4.11.

Bjorn

Re: [PATCH v2] PCI: Add information about describing PCI in ACPI

[Bjorn Helgaas]

On Tue, Dec 13, 2016 at 04:09:39AM -0500, Jon Masters wrote:
> On 11/29/2016 04:39 PM, Bjorn Helgaas wrote:
> 
> > +New architectures should be able to use "Consumer" Extended Address Space
> > +descriptors in the PNP0A03 device for bridge registers, including ECAM,
> > +although a strict interpretation of [6] might prohibit this.  Old x86 and
> > +ia64 kernels assume all address space descriptors, including "Consumer"
> > +Extended Address Space ones, are windows, so it would not be safe to
> > +describe bridge registers this way on those architectures.
> 
> <snip>
> 
> > +[6] PCI Firmware 3.0, sec 4.1.2:
> 
> <snip>
> 
> Thanks for the revised writeup, Bjorn. It's great. I'm trying to get the
> above clarified explicitly in terms of the spec, and in terms of what
> other Operating Systems would like to see as general preference.

Any feedback on this?  I'd like to post a revised version soon for v4.11.

Bjorn

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2] PCI: Add information about describing PCI in ACPI

[Bjorn Helgaas]

On Tue, Dec 13, 2016 at 04:09:39AM -0500, Jon Masters wrote:
> On 11/29/2016 04:39 PM, Bjorn Helgaas wrote:
> 
> > +New architectures should be able to use "Consumer" Extended Address Space
> > +descriptors in the PNP0A03 device for bridge registers, including ECAM,
> > +although a strict interpretation of [6] might prohibit this.  Old x86 and
> > +ia64 kernels assume all address space descriptors, including "Consumer"
> > +Extended Address Space ones, are windows, so it would not be safe to
> > +describe bridge registers this way on those architectures.
> 
> <snip>
> 
> > +[6] PCI Firmware 3.0, sec 4.1.2:
> 
> <snip>
> 
> Thanks for the revised writeup, Bjorn. It's great. I'm trying to get the
> above clarified explicitly in terms of the spec, and in terms of what
> other Operating Systems would like to see as general preference.

Any feedback on this?  I'd like to post a revised version soon for v4.11.

Bjorn