BMC/Intel-BMC/linux.git/drivers/pci/probe.c, branch dev-4.18

PCI: Match Root Port's MPS to endpoint's MPSS as necessary

2018-09-15T07:46:50+00:00

[ Upstream commit 9f0e89359775ee21fe1ea732e34edb52aef5addf ] In commit 27d868b5e6cf ("PCI: Set MPS to match upstream bridge"), we made sure every device's MPS setting matches its upstream bridge, making it more likely that a hot-added device will work in a system with an optimized MPS configuration. Recently I've started encountering systems where the endpoint device's MPSS capability is less than its Root Port's current MPS value, thus the endpoint is not capable of matching its upstream bridge's MPS setting (see: bugzilla via "Link:" below). This leaves the system vulnerable - the upstream Root Port could respond with larger TLPs than the device can handle, and the device will consider them to be 'Malformed'. One could use the "pci=pcie_bus_safe" kernel parameter to work around the issue, but that forces a user to supply a kernel parameter to get the system to function reliably and may end up limiting MPS settings of other unrelated, sub-topologies which could benefit from maintaining their larger values. Augment Keith's approach to include tuning down a Root Port's MPS setting when its hot-added endpoint device is not capable of matching it. Link: https://bugzilla.kernel.org/show_bug.cgi?id=200527 Signed-off-by: Myron Stowe Signed-off-by: Bjorn Helgaas Acked-by: Jon Mason Cc: Keith Busch Cc: Sinan Kaya Cc: Dongdong Liu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

PCI: Skip MPS logic for Virtual Functions (VFs)

2018-08-24T11:04:50+00:00

commit 3dbe97efe8bf450b183d6dee2305cbc032e6b8a4 upstream. PCIe r4.0, sec 9.3.5.4, "Device Control Register", shows both Max_Payload_Size (MPS) and Max_Read_request_Size (MRRS) to be 'RsvdP' for VFs. Just prior to the table it states: "PF and VF functionality is defined in Section 7.5.3.4 except where noted in Table 9-16. For VF fields marked 'RsvdP', the PF setting applies to the VF." All of which implies that with respect to Max_Payload_Size Supported (MPSS), MPS, and MRRS values, we should not be paying any attention to the VF's fields, but rather only to the PF's. Only looking at the PF's fields also logically makes sense as it's the sole physical interface to the PCIe bus. Link: https://bugzilla.kernel.org/show_bug.cgi?id=200527 Fixes: 27d868b5e6cf ("PCI: Set MPS to match upstream bridge") Signed-off-by: Myron Stowe Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org # 4.3+ Cc: Keith Busch Cc: Sinan Kaya Cc: Dongdong Liu Cc: Jon Mason Signed-off-by: Greg Kroah-Hartman

PCI: Fix is_added/is_busmaster race condition

2018-07-31T16:27:54+00:00

When a PCI device is detected, pdev->is_added is set to 1 and proc and sysfs entries are created. When the device is removed, pdev->is_added is checked for one and then device is detached with clearing of proc and sys entries and at end, pdev->is_added is set to 0. is_added and is_busmaster are bit fields in pci_dev structure sharing same memory location. A strange issue was observed with multiple removal and rescan of a PCIe NVMe device using sysfs commands where is_added flag was observed as zero instead of one while removing device and proc,sys entries are not cleared. This causes issue in later device addition with warning message "proc_dir_entry" already registered. Debugging revealed a race condition between the PCI core setting the is_added bit in pci_bus_add_device() and the NVMe driver reset work-queue setting the is_busmaster bit in pci_set_master(). As these fields are not handled atomically, that clears the is_added bit. Move the is_added bit to a separate private flag variable and use atomic functions to set and retrieve the device addition state. This avoids the race because is_added no longer shares a memory location with is_busmaster. Link: https://bugzilla.kernel.org/show_bug.cgi?id=200283 Signed-off-by: Hari Vyas Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Acked-by: Michael Ellerman

Merge branch 'pci/resource'

2018-06-06T21:10:18+00:00

- add managed interface to get PCI host bridge resources from OF (Jan Kiszka) - add support for unbinding generic PCI host controller (Jan Kiszka) - fix memory leaks when unbinding generic PCI host controller (Jan Kiszka) * pci/resource: PCI: Enable PCI_DOMAINS along with generic PCI host controller PCI: Add support for unbinding the generic PCI host controller PCI: Rework of_pci_get_host_bridge_resources() to devm_of_pci_get_host_bridge_resources() PCI: Use dev_printk() in of_pci_get_host_bridge_resources() PCI: Pass struct device to of_pci_get_host_bridge_resources() PCI: Rename of_pci_get_host_bridge_resources() device node parameter PCI: Fix devm_pci_alloc_host_bridge() memory leak PCI: Make pci_get_new_domain_nr() static

Merge branch 'pci/hotplug'

2018-06-06T21:10:10+00:00

- fix use-before-set error in ibmphp (Dan Carpenter) - fix pciehp timeouts caused by Command Completed errata (Bjorn Helgaas) - fix refcounting in pnv_php hotplug (Julia Lawall) - clear pciehp Presence Detect and Data Link Layer Status Changed on resume so we don't miss hotplug events (Mika Westerberg) - only request pciehp control if we support it, so platform can use ACPI hotplug otherwise (Mika Westerberg) - convert SHPC to be builtin only (Mika Westerberg) - request SHPC control via _OSC if we support it (Mika Westerberg) - simplify SHPC handoff from firmware (Mika Westerberg) * pci/hotplug: PCI: Improve "partially hidden behind bridge" log message PCI: Improve pci_scan_bridge() and pci_scan_bridge_extend() doc PCI: Move resource distribution for single bridge outside loop PCI: Account for all bridges on bus when distributing bus numbers ACPI / hotplug / PCI: Drop unnecessary parentheses ACPI / hotplug / PCI: Mark stale PCI devices disconnected ACPI / hotplug / PCI: Don't scan bridges managed by native hotplug PCI: hotplug: Add hotplug_is_native() PCI: shpchp: Add shpchp_is_native() PCI: shpchp: Fix AMD POGO identification PCI: shpchp: Use dev_printk() for OSHP-related messages PCI: shpchp: Remove get_hp_hw_control_from_firmware() wrapper PCI: shpchp: Remove acpi_get_hp_hw_control_from_firmware() flags PCI: shpchp: Rely on previous _OSC results PCI: shpchp: Request SHPC control via _OSC when adding host bridge PCI: shpchp: Convert SHPC to be builtin only PCI: pciehp: Make pciehp_is_native() stricter PCI: pciehp: Rename host->native_hotplug to host->native_pcie_hotplug PCI: pciehp: Request control of native hotplug only if supported PCI: pciehp: Clear Presence Detect and Data Link Layer Status Changed on resume PCI: pnv_php: Add missing of_node_put() PCI: pciehp: Add quirk for Command Completed errata PCI: Add Qualcomm vendor ID PCI: ibmphp: Fix use-before-set in get_max_bus_speed() # Conflicts: # drivers/acpi/pci_root.c

Merge branch 'pci/enumeration'

2018-06-06T21:10:08+00:00

- neaten pci=earlydump output (Andy Shevchenko) - avoid errors when extended config space inaccessible (Gilles Buloz) - prevent sysfs disable of device while driver attached (Christoph Hellwig) - use core interface to report PCIe link properties in bnx2x, bnxt_en, cxgb4, ixgbe (Bjorn Helgaas) - remove unused pcie_get_minimum_link() (Bjorn Helgaas) * pci/enumeration: PCI: Remove unused pcie_get_minimum_link() ixgbe: Report PCIe link properties with pcie_print_link_status() cxgb4: Report PCIe link properties with pcie_print_link_status() bnxt_en: Report PCIe link properties with pcie_print_link_status() bnx2x: Report PCIe link properties with pcie_print_link_status() PCI: Prevent sysfs disable of device while driver is attached PCI: Check whether bridges allow access to extended config space x86/PCI: Make pci=earlydump output neat

PCI: Improve "partially hidden behind bridge" log message

2018-06-04T17:08:06+00:00

pci_scan_child_bus_extend() complains when we assign an unreachable secondary bus number to a bridge. For example, given the topology below: +-1b.0-[01-39]----00.0-[02-3a]--+-00.0-[03]----00.0 +-01.0-[04-39]-- \-02.0-[3a]----00.0 it logs the following messages: pci_bus 0000:3a: [bus 3a] partially hidden behind bridge 0000:02 [bus 02-39] pci_bus 0000:3a: [bus 3a] partially hidden behind bridge 0000:01 [bus 01-39] These messages are incorrect (0000:02 is a bus, not a bridge) and confusing. Make the message more understandable: pci 0000:02:02.0: devices behind bridge are unusable because [bus 3a] cannot be assigned for them Also, remove the reference to CardBus, because this issue affects all varieties of PCI, not just CardBus. Suggested-by: Bjorn Helgaas Signed-off-by: Mika Westerberg [bhelgaas: changelog] Signed-off-by: Bjorn Helgaas

PCI: Improve pci_scan_bridge() and pci_scan_bridge_extend() doc

2018-06-04T17:08:06+00:00

It is not immediately clear what the two functions actually return so add kernel-doc comment explaining it a bit better. Suggested-by: Bjorn Helgaas Signed-off-by: Mika Westerberg Signed-off-by: Bjorn Helgaas Reviewed-by: Rafael J. Wysocki Reviewed-by: Andy Shevchenko

PCI: Account for all bridges on bus when distributing bus numbers

2018-06-04T17:08:06+00:00

When distributing extra bus number space to hotplug bridges for future extension, we don't account for the fact that there might be non-hotplug bridges on the bus after the hotplug bridges. For example: 01:00.0 --+- 02:00.0 (HotPlug-) -- Thunderbolt host controller +- 02:01.0 (HotPlug+) \- 02:02.0 (HotPlug-) -- xHCI host controller pci_scan_child_bus_extend() is supposed to distribute the remaining bus numbers to the hotplug bridge at 02:01.0, but only after accounting for all bridges on bus 02. Since we don't check whether there's another non-hotplug bridge after the hotplug bridge 02:01.0, it may not leave space for the non-hotplug bridge: pci 0000:00:1b.0: PCI bridge to [bus 01-39] (Root Port) pci 0000:01:00.0: PCI bridge to [bus 02-39] ... pci 0000:02:00.0: PCI bridge to [bus 03] pci 0000:02:01.0: PCI bridge to [bus 04] pci_bus 0000:04: [bus 04-39] extended by 0x35 pci_bus 0000:04: bus scan returning with max=39 pci_bus 0000:04: busn_res: [bus 04-39] end is updated to 39 pci 0000:02:02.0: scanning [bus 00-00] behind bridge, pass 1 pci_bus 0000:3a: scanning bus pci_bus 0000:3a: bus scan returning with max=3a pci_bus 0000:3a: busn_res: [bus 3a] end is updated to 3a pci_bus 0000:3a: [bus 3a] partially hidden behind bridge 0000:02 [bus 02-39] pci_bus 0000:3a: [bus 3a] partially hidden behind bridge 0000:01 [bus 01-39] pci_bus 0000:02: bus scan returning with max=3a pci_bus 0000:02: busn_res: [bus 02-39] end can not be updated to 3a The resulting 'lspci -t' output looks like this: +-1b.0-[01-39]----00.0-[02-3a]--+-00.0-[03]----00.0 ^^ +-01.0-[04-39]-- \-02.0-[3a]----00.0 ^^ The xHCI host controller behind 02:02.0 is not usable because it would have to be assigned bus 3a, which is not accessible through 00:1b.0. To fix this, reserve at least one bus for each bridge while scanning already configured bridges. Then use this information in the second scan to correct the available extra bus space for hotplug bridges. After this change the 'lspci -t' output is what is expected: +-1b.0-[01-39]----00.0-[02-39]--+-00.0-[03]----00.0 +-01.0-[04-38]-- \-02.0-[39]----00.0 The xHCI controller is now on bus 39, where it is usable. Fixes: 1c02ea810065 ("PCI: Distribute available buses to hotplug-capable bridges") Reported-by: Mario Limonciello Signed-off-by: Mika Westerberg [bhelgaas: changelog] Signed-off-by: Bjorn Helgaas Reviewed-by: Rafael J. Wysocki Reviewed-by: Andy Shevchenko Cc: stable@vger.kernel.org

PCI: shpchp: Request SHPC control via _OSC when adding host bridge

2018-06-02T05:18:28+00:00

The SHPC driver now must be builtin (it cannot be a module). If it is present, request SHPC control immediately when adding the ACPI host bridge. This is similar to how we handle native PCIe hotplug via pciehp. Suggested-by: Bjorn Helgaas Signed-off-by: Mika Westerberg [bhelgaas: split to separate patch] Signed-off-by: Bjorn Helgaas Reviewed-by: Rafael J. Wysocki