From c3aaf086701d05a82c8156ee8620af41e5a7d6fe Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Tue, 7 Apr 2020 18:23:15 -0500 Subject: PCI/PM: Call .bridge_d3() hook only if non-NULL 26ad34d510a8 ("PCI / ACPI: Whitelist D3 for more PCIe hotplug ports") added the struct pci_platform_pm_ops.bridge_d3() function pointer and platform_pci_bridge_d3() to use it. The .bridge_d3() op is implemented by acpi_pci_platform_pm, but not by mid_pci_platform_pm. We don't expect platform_pci_bridge_d3() to be called on Intel MID platforms, but nothing in the code itself would prevent that. Check the .bridge_d3() pointer for NULL before calling it. Fixes: 26ad34d510a8 ("PCI / ACPI: Whitelist D3 for more PCIe hotplug ports") Signed-off-by: Bjorn Helgaas Reviewed-by: Mika Westerberg --- drivers/pci/pci.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'drivers/pci/pci.c') diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 595fcf59843f..dfa7ec008963 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -868,7 +868,9 @@ static inline bool platform_pci_need_resume(struct pci_dev *dev) static inline bool platform_pci_bridge_d3(struct pci_dev *dev) { - return pci_platform_pm ? pci_platform_pm->bridge_d3(dev) : false; + if (pci_platform_pm && pci_platform_pm->bridge_d3) + return pci_platform_pm->bridge_d3(dev); + return false; } /** -- cgit v1.2.3-70-g09d2 From 914a1951d88968371c7d43400c9d936382cd7d69 Mon Sep 17 00:00:00 2001 From: "Gustavo A. R. Silva" Date: Thu, 7 May 2020 14:05:44 -0500 Subject: PCI: Replace zero-length array with flexible-array The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these as a flexible array member [1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that dynamic memory allocations won't be affected by this change: Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero. [1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type [1]. There are some instances of code in which the sizeof() operator is being incorrectly/erroneously applied to zero-length arrays, and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Link: https://lore.kernel.org/r/20200507190544.GA15633@embeddedor Signed-off-by: Gustavo A. R. Silva Signed-off-by: Bjorn Helgaas --- drivers/pci/pci.c | 2 +- include/linux/pci.h | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) (limited to 'drivers/pci/pci.c') diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 595fcf59843f..bb78f580814e 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -1578,7 +1578,7 @@ EXPORT_SYMBOL(pci_restore_state); struct pci_saved_state { u32 config_space[16]; - struct pci_cap_saved_data cap[0]; + struct pci_cap_saved_data cap[]; }; /** diff --git a/include/linux/pci.h b/include/linux/pci.h index 83ce1cdf5676..0453ee458ab1 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -279,7 +279,7 @@ struct pci_cap_saved_data { u16 cap_nr; bool cap_extended; unsigned int size; - u32 data[0]; + u32 data[]; }; struct pci_cap_saved_state { @@ -532,7 +532,7 @@ struct pci_host_bridge { resource_size_t start, resource_size_t size, resource_size_t align); - unsigned long private[0] ____cacheline_aligned; + unsigned long private[] ____cacheline_aligned; }; #define to_pci_host_bridge(n) container_of(n, struct pci_host_bridge, dev) -- cgit v1.2.3-70-g09d2 From 6ae72bfa656ea04806f98ef85cb44b0789064362 Mon Sep 17 00:00:00 2001 From: Yicong Yang Date: Sat, 9 May 2020 18:19:28 +0800 Subject: PCI: Unify pcie_find_root_port() and pci_find_pcie_root_port() Previously we used pcie_find_root_port() to find a Root Port from a PCIe device and pci_find_pcie_root_port() to find a Root Port from a Conventional PCI device. Unify the two functions and use pcie_find_root_port() to find a Root Port from either a Conventional PCI device or a PCIe device. Then there is no need to distinguish the type of the device. Link: https://lore.kernel.org/r/1589019568-5216-1-git-send-email-yangyicong@hisilicon.com Signed-off-by: Yicong Yang Signed-off-by: Bjorn Helgaas Acked-by: Kalle Valo # wireless Acked-by: Mika Westerberg # thunderbolt --- drivers/pci/pci-acpi.c | 2 +- drivers/pci/pci.c | 24 ------------------------ drivers/pci/probe.c | 2 +- drivers/pci/quirks.c | 2 +- drivers/thunderbolt/switch.c | 4 ++-- include/linux/pci.h | 23 ++++++++++++++--------- 6 files changed, 19 insertions(+), 38 deletions(-) (limited to 'drivers/pci/pci.c') diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c index d21969fba6ab..d820a55ae71c 100644 --- a/drivers/pci/pci-acpi.c +++ b/drivers/pci/pci-acpi.c @@ -948,7 +948,7 @@ static bool acpi_pci_bridge_d3(struct pci_dev *dev) * Look for a special _DSD property for the root port and if it * is set we know the hierarchy behind it supports D3 just fine. */ - root = pci_find_pcie_root_port(dev); + root = pcie_find_root_port(dev); if (!root) return false; diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index bb78f580814e..227a3a979ec4 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -751,30 +751,6 @@ struct resource *pci_find_resource(struct pci_dev *dev, struct resource *res) } EXPORT_SYMBOL(pci_find_resource); -/** - * pci_find_pcie_root_port - return PCIe Root Port - * @dev: PCI device to query - * - * Traverse up the parent chain and return the PCIe Root Port PCI Device - * for a given PCI Device. - */ -struct pci_dev *pci_find_pcie_root_port(struct pci_dev *dev) -{ - struct pci_dev *bridge, *highest_pcie_bridge = dev; - - bridge = pci_upstream_bridge(dev); - while (bridge && pci_is_pcie(bridge)) { - highest_pcie_bridge = bridge; - bridge = pci_upstream_bridge(bridge); - } - - if (pci_pcie_type(highest_pcie_bridge) != PCI_EXP_TYPE_ROOT_PORT) - return NULL; - - return highest_pcie_bridge; -} -EXPORT_SYMBOL(pci_find_pcie_root_port); - /** * pci_wait_for_pending - wait for @mask bit(s) to clear in status word @pos * @dev: the PCI device to operate on diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 77b8a145c39b..cdff469ba070 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -2056,7 +2056,7 @@ static void pci_configure_relaxed_ordering(struct pci_dev *dev) * For now, we only deal with Relaxed Ordering issues with Root * Ports. Peer-to-Peer DMA is another can of worms. */ - root = pci_find_pcie_root_port(dev); + root = pcie_find_root_port(dev); if (!root) return; diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 28c9a2409c50..885044d050a6 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -4319,7 +4319,7 @@ DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, 0x1a02, PCI_CLASS_NOT_DEFINED, */ static void quirk_disable_root_port_attributes(struct pci_dev *pdev) { - struct pci_dev *root_port = pci_find_pcie_root_port(pdev); + struct pci_dev *root_port = pcie_find_root_port(pdev); if (!root_port) { pci_warn(pdev, "PCIe Completion erratum may cause device errors\n"); diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c index a2ce99051c51..d92c7554520b 100644 --- a/drivers/thunderbolt/switch.c +++ b/drivers/thunderbolt/switch.c @@ -263,7 +263,7 @@ static void nvm_authenticate_start_dma_port(struct tb_switch *sw) * itself. To be on the safe side keep the root port in D0 during * the whole upgrade process. */ - root_port = pci_find_pcie_root_port(sw->tb->nhi->pdev); + root_port = pcie_find_root_port(sw->tb->nhi->pdev); if (root_port) pm_runtime_get_noresume(&root_port->dev); } @@ -272,7 +272,7 @@ static void nvm_authenticate_complete_dma_port(struct tb_switch *sw) { struct pci_dev *root_port; - root_port = pci_find_pcie_root_port(sw->tb->nhi->pdev); + root_port = pcie_find_root_port(sw->tb->nhi->pdev); if (root_port) pm_runtime_put(&root_port->dev); } diff --git a/include/linux/pci.h b/include/linux/pci.h index 0453ee458ab1..bbd6510065a7 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -1025,7 +1025,6 @@ void pci_bus_add_device(struct pci_dev *dev); void pci_read_bridge_bases(struct pci_bus *child); struct resource *pci_find_parent_resource(const struct pci_dev *dev, struct resource *res); -struct pci_dev *pci_find_pcie_root_port(struct pci_dev *dev); u8 pci_swizzle_interrupt_pin(const struct pci_dev *dev, u8 pin); int pci_get_interrupt_pin(struct pci_dev *dev, struct pci_dev **bridge); u8 pci_common_swizzle(struct pci_dev *dev, u8 *pinp); @@ -2143,17 +2142,23 @@ static inline int pci_pcie_type(const struct pci_dev *dev) return (pcie_caps_reg(dev) & PCI_EXP_FLAGS_TYPE) >> 4; } +/** + * pcie_find_root_port - Get the PCIe root port device + * @dev: PCI device + * + * Traverse up the parent chain and return the PCIe Root Port PCI Device + * for a given PCI/PCIe Device. + */ static inline struct pci_dev *pcie_find_root_port(struct pci_dev *dev) { - while (1) { - if (!pci_is_pcie(dev)) - break; - if (pci_pcie_type(dev) == PCI_EXP_TYPE_ROOT_PORT) - return dev; - if (!dev->bus->self) - break; - dev = dev->bus->self; + struct pci_dev *bridge = pci_upstream_bridge(dev); + + while (bridge) { + if (pci_pcie_type(bridge) == PCI_EXP_TYPE_ROOT_PORT) + return bridge; + bridge = pci_upstream_bridge(bridge); } + return NULL; } -- cgit v1.2.3-70-g09d2 From f044baaff1eb7ae5aa7a36f1b7ad5bd8eeb672c4 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Fri, 15 May 2020 14:31:16 -0500 Subject: PCI/PM: Adjust pcie_wait_for_link_delay() for caller delay The caller of pcie_wait_for_link_delay() specifies the time to wait after the link becomes active. When the downstream port doesn't support link active reporting, obviously we can't tell when the link becomes active, so we waited the worst-case time (1000 ms) plus 100 ms, ignoring the delay from the caller. Instead, wait for 1000 ms + the delay from the caller. Fixes: 4827d63891b6 ("PCI/PM: Add pcie_wait_for_link_delay()") Signed-off-by: Bjorn Helgaas --- drivers/pci/pci.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'drivers/pci/pci.c') diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index dfa7ec008963..a4efc7e0061f 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -4675,10 +4675,10 @@ static bool pcie_wait_for_link_delay(struct pci_dev *pdev, bool active, /* * Some controllers might not implement link active reporting. In this - * case, we wait for 1000 + 100 ms. + * case, we wait for 1000 ms + any delay requested by the caller. */ if (!pdev->link_active_reporting) { - msleep(1100); + msleep(timeout + delay); return true; } -- cgit v1.2.3-70-g09d2 From ec411e02b7a2e785a4ed9ed283207cd14f48699d Mon Sep 17 00:00:00 2001 From: Mika Westerberg Date: Thu, 14 May 2020 16:30:43 +0300 Subject: PCI/PM: Assume ports without DLL Link Active train links in 100 ms Kai-Heng Feng reported that it takes a long time (> 1 s) to resume Thunderbolt-connected devices from both runtime suspend and system sleep (s2idle). This was because some Downstream Ports that support > 5 GT/s do not also support Data Link Layer Link Active reporting. Per PCIe r5.0 sec 6.6.1: With a Downstream Port that supports Link speeds greater than 5.0 GT/s, software must wait a minimum of 100 ms after Link training completes before sending a Configuration Request to the device immediately below that Port. Software can determine when Link training completes by polling the Data Link Layer Link Active bit or by setting up an associated interrupt (see Section 6.7.3.3). Sec 7.5.3.6 requires such Ports to support DLL Link Active reporting, but at least the Intel JHL6240 Thunderbolt 3 Bridge [8086:15c0] and the Intel JHL7540 Thunderbolt 3 Bridge [8086:15ea] do not. Previously we tried to wait for Link training to complete, but since there was no DLL Link Active reporting, all we could do was wait the worst-case 1000 ms, then another 100 ms. Instead of using the supported speeds to determine whether to wait for Link training, check whether the port supports DLL Link Active reporting. The Ports in question do not, so we'll wait only the 100 ms required for Ports that support Link speeds <= 5 GT/s. This of course assumes these Ports always train the Link within 100 ms even if they are operating at > 5 GT/s, which is not required by the spec. [bhelgaas: commit log, comment] Link: https://bugzilla.kernel.org/show_bug.cgi?id=206837 Link: https://lore.kernel.org/r/20200514133043.27429-1-mika.westerberg@linux.intel.com Reported-by: Kai-Heng Feng Tested-by: Kai-Heng Feng Signed-off-by: Mika Westerberg Signed-off-by: Bjorn Helgaas --- drivers/pci/pci.c | 30 +++++++++++++++++++++--------- 1 file changed, 21 insertions(+), 9 deletions(-) (limited to 'drivers/pci/pci.c') diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index a4efc7e0061f..d4758518a97b 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -4662,7 +4662,8 @@ static int pci_pm_reset(struct pci_dev *dev, int probe) * pcie_wait_for_link_delay - Wait until link is active or inactive * @pdev: Bridge device * @active: waiting for active or inactive? - * @delay: Delay to wait after link has become active (in ms) + * @delay: Delay to wait after link has become active (in ms). Specify %0 + * for no delay. * * Use this to wait till link becomes active or inactive. */ @@ -4703,7 +4704,7 @@ static bool pcie_wait_for_link_delay(struct pci_dev *pdev, bool active, msleep(10); timeout -= 10; } - if (active && ret) + if (active && ret && delay) msleep(delay); else if (ret != active) pci_info(pdev, "Data Link Layer Link Active not %s in 1000 msec\n", @@ -4824,17 +4825,28 @@ void pci_bridge_wait_for_secondary_bus(struct pci_dev *dev) if (!pcie_downstream_port(dev)) return; - if (pcie_get_speed_cap(dev) <= PCIE_SPEED_5_0GT) { - pci_dbg(dev, "waiting %d ms for downstream link\n", delay); - msleep(delay); - } else { - pci_dbg(dev, "waiting %d ms for downstream link, after activation\n", - delay); - if (!pcie_wait_for_link_delay(dev, true, delay)) { + /* + * Per PCIe r5.0, sec 6.6.1, for downstream ports that support + * speeds > 5 GT/s, we must wait for link training to complete + * before the mandatory delay. + * + * We can only tell when link training completes via DLL Link + * Active, which is required for downstream ports that support + * speeds > 5 GT/s (sec 7.5.3.6). Unfortunately some common + * devices do not implement Link Active reporting even when it's + * required, so we'll check for that directly instead of checking + * the supported link speed. We assume devices without Link Active + * reporting can train in 100 ms regardless of speed. + */ + if (dev->link_active_reporting) { + pci_dbg(dev, "waiting for link to train\n"); + if (!pcie_wait_for_link_delay(dev, true, 0)) { /* Did not train, no need to wait any further */ return; } } + pci_dbg(child, "waiting %d ms to become accessible\n", delay); + msleep(delay); if (!pci_device_is_present(child)) { pci_dbg(child, "waiting additional %d ms to become accessible\n", delay); -- cgit v1.2.3-70-g09d2