summaryrefslogtreecommitdiff
path: root/drivers/pci
AgeCommit message (Collapse)Author
2022-10-05PCI/ASPM: Factor out L1 PM Substates configurationBjorn Helgaas
Move L1 PM Substates configuration from pcie_aspm_cap_init() to a new aspm_l1ss_init() function. No functional change intended. Link: https://lore.kernel.org/r/20221005025809.2247547-2-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
2022-10-05PCI: qcom-ep: Gate Master AXI clock to MHI bus during L1SSManivannan Sadhasivam
During L1SS, gate the Master clock supplied to the MHI bus to save power. Link: https://lore.kernel.org/r/20220914075350.7992-7-manivannan.sadhasivam@linaro.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
2022-10-05PCI: qcom-ep: Expose link transition counts via debugfsManivannan Sadhasivam
Qualcomm PCIe controllers have debug registers in the MMIO region that count PCIe link transitions. Expose them over debugfs to userspace to help debug the low power issues. Link: https://lore.kernel.org/r/20220914075350.7992-6-manivannan.sadhasivam@linaro.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
2022-10-05PCI: qcom-ep: Disable IRQs during driver removeManivannan Sadhasivam
Disable the Global and PERST IRQs during driver remove to avoid getting spurious IRQs after resource deallocation. Link: https://lore.kernel.org/r/20220914075350.7992-5-manivannan.sadhasivam@linaro.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
2022-10-04PCI/ASPM: Save L1 PM Substates Capability for suspend/resumeVidya Sagar
Previously the L1 PM Substates Control Registers (CTL1 and CTL2) weren't saved and restored during suspend/resume leading to the L1 PM Substates configuration being lost post-resume. Save the L1 PM Substates Control Registers so that the configuration is retained post-resume. [bhelgaas: drop pci_is_pcie() testing; we can rely on pci_configure_ltr() having already done that] Link: https://lore.kernel.org/r/20220913131822.16557-3-vidyas@nvidia.com Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2022-10-04PCI/ASPM: Refactor L1 PM Substates Control Register programmingVidya Sagar
Refactor the code to extract the common code to program Control Registers 1 and 2 of the L1 PM Substates capability to a new function aspm_program_l1ss() and call it for both parent and child devices. [bhelgaas: squash in update to preserve fields we're not updating from https://lore.kernel.org/r/36fa13c5-e0f8-022f-77f7-7908e4df98b8@nvidia.com] Link: https://lore.kernel.org/r/20220913131822.16557-2-vidyas@nvidia.com Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2022-10-04xen-pcifront: Handle missed Connected stateJason Andryuk
An HVM guest with linux stubdomain and 2 PCI devices failed to start as libxl timed out waiting for the PCI devices to be added. It happens intermittently but with some regularity. libxl wrote the two xenstore entries for the devices, but then timed out waiting for backend state 4 (Connected) - the state stayed at 7 (Reconfiguring). (PCI passthrough to an HVM with stubdomain is PV passthrough to the stubdomain and then HVM passthrough with the QEMU inside the stubdomain.) The stubdomain kernel never printed "pcifront pci-0: Installing PCI frontend", so it seems to have missed state 4 which would have called pcifront_try_connect() -> pcifront_connect_and_init_dma() Have pcifront_detach_devices() special-case state Initialised and call pcifront_connect_and_init_dma(). Don't use pcifront_try_connect() because that sets the xenbus state which may throw off the backend. After connecting, skip the remainder of detach_devices since none have been initialized yet. When the backend switches to Reconfigured, pcifront_attach_devices() will pick them up again. Signed-off-by: Jason Andryuk <jandryuk@gmail.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20220829151536.8578-1-jandryuk@gmail.com Signed-off-by: Juergen Gross <jgross@suse.com>
2022-10-03PCI: qcom-ep: Make use of the cached dev pointerManivannan Sadhasivam
In the qcom_pcie_ep_get_resources() function, dev pointer is already cached in a local variable. So let's make use of it instead of getting the dev pointer again from pdev struct. Link: https://lore.kernel.org/r/20220914075350.7992-4-manivannan.sadhasivam@linaro.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
2022-10-03PCI: qcom-ep: Rely on the clocks supplied by devicetreeManivannan Sadhasivam
Generally, device drivers should just rely on the platform data like devicetree to supply the clocks required for the functioning of the peripheral. There is no need to hardcode the clk info in the driver. So get rid of the static clk info and obtain the platform supplied clks. The total number of clocks supplied is obtained using the devm_clk_bulk_get_all() API and used for the rest of the clk_bulk_ APIs. Link: https://lore.kernel.org/r/20220914075350.7992-3-manivannan.sadhasivam@linaro.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
2022-10-03PCI: qcom-ep: Add kernel-doc for qcom_pcie_ep structureManivannan Sadhasivam
Add kernel-doc for qcom_pcie_ep structure. Link: https://lore.kernel.org/r/20220914075350.7992-2-manivannan.sadhasivam@linaro.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
2022-10-03phy: freescale: imx8m-pcie: Fix the wrong order of phy_init() and phy_power_on()Richard Zhu
Refer to phy_core driver, phy_init() must be called before phy_power_on(). Fix the wrong order of phy_init() and phy_power_on() here. Link: https://lore.kernel.org/r/1662344583-18874-1-git-send-email-hongxing.zhu@nxp.com Fixes: 1aa97b002258 ("phy: freescale: pcie: Initialize the imx8 pcie standalone phy driver") Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Acked-by: Vinod Koul <vkoul@kernel.org> Acked-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
2022-10-03PCI: imx6: Add i.MX8MP PCIe supportRichard Zhu
Add i.MX8MP PCIe support. To avoid codes duplication when find the syscon regmap, add the iomux gpr syscon compatible into drvdata. Link: https://lore.kernel.org/r/1662109086-15881-8-git-send-email-hongxing.zhu@nxp.com Tested-by: Marek Vasut <marex@denx.de> Tested-by: Richard Leitner <richard.leitner@skidata.com> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
2022-10-03PCI: dwc: Replace of_gpio_named_count() by gpiod_count()Andy Shevchenko
As a preparation to unexport of_gpio_named_count(), convert the driver to use gpiod_count() instead. Link: https://lore.kernel.org/r/20220830183310.48541-1-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Acked-by: Rob Herring <robh@kernel.org>
2022-09-29PCI/PM: Reduce D3hot delay with usleep_range()Sajid Dalvi
PCIe r6.0, sec 5.9, requires a 10ms delay between programming a device to change to or from D3hot and the time the device is next accessed (unless Readiness Notifications are used). The 10ms value (PCI_PM_D3HOT_WAIT) doesn't appear directly here because some chipsets require 120ms for devices *below* them (pci_pm_d3hot_delay) and some devices require more or less than 10ms (dev->d3hot_delay). But msleep(10) typically waits about *20*ms, which is more than we need. Switch to usleep_range() to improve the delay accuracy. Based on a commit from Sajid in the Pixel 6 kernel tree [1]. On a Pixel 6, the 10ms delay for the Exynos PCIe device delayed for an average of 19ms. Switching to usleep_range() decreased the resume time by about 9ms. [1] https://android.googlesource.com/kernel/gs/+/18a8cad68d8e6d50f339a716a18295e6d987cee3 [bhelgaas commit log, add timers-howto.rst link] Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/timers/timers-howto.rst?id=v5.19#n73 Link: https://lore.kernel.org/r/20220921212735.2131588-1-willmcvicker@google.com Signed-off-by: Sajid Dalvi <sdalvi@google.com> Signed-off-by: Will McVicker <willmcvicker@google.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
2022-09-29PCI: tegra: Use PCI_CONF1_EXT_ADDRESS() macroPali Rohár
Simplify pci-tegra.c driver code and use new PCI_CONF1_EXT_ADDRESS() macro for accessing PCI config space. Link: https://lore.kernel.org/r/20220928121911.14994-1-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Acked-by: Thierry Reding <treding@nvidia.com>
2022-09-29PCI: qcom: Rename host-init error labelJohan Hovold
Use a more descriptive name for the reset host-init error label for consistency. Link: https://lore.kernel.org/r/20220928155421.21660-3-johan+linaro@kernel.org Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
2022-09-29PCI: qcom: Drop unused post_deinit callbackJohan Hovold
Drop the unused and confusingly named post_deinit callback that was added for the now removed pipe clock handling. If ever needed we can add back a callback named pre_deinit (or perhaps rather pre_phy_power_off) instead. Link: https://lore.kernel.org/r/20220928155421.21660-2-johan+linaro@kernel.org Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
2022-09-27PCI/DPC: Quirk PIO log size for certain Intel Root PortsMika Westerberg
Some Root Ports on Intel Tiger Lake and Alder Lake systems support the RP Extensions for DPC and the RP PIO Log registers but incorrectly advertise an RP PIO Log Size of zero. This means the kernel complains that: DPC: RP PIO log size 0 is invalid and if DPC is triggered, the DPC driver will not dump the RP PIO Log registers when it should. This is caused by a BIOS bug and should be fixed the BIOS for future CPUs. Add a quirk to set the correct RP PIO Log size for the affected Root Ports. Link: https://bugzilla.kernel.org/show_bug.cgi?id=209943 Link: https://lore.kernel.org/r/20220816102042.69125-1-mika.westerberg@linux.intel.com Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
2022-09-27PCI: mt7621: Use PCI_CONF1_EXT_ADDRESS() macroPali Rohár
Simplify pcie-mt7621.c driver code and use new PCI_CONF1_EXT_ADDRESS() macro for accessing PCIe config space. Link: https://lore.kernel.org/r/20220924092404.31776-4-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Acked-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
2022-09-27PCI: ftpci100: Use PCI_CONF1_ADDRESS() macroPali Rohár
Simplify pci-ftpci100.c driver code and use new PCI_CONF1_ADDRESS() macro for accessing PCI config space. Link: https://lore.kernel.org/r/20220924092404.31776-3-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
2022-09-27PCI: Add standard PCI Config Address macrosPali Rohár
Lot of PCI and PCIe controllers are using standard Config Address for PCI Configuration Mechanism #1 (as defined in PCI Local Bus Specification) or its extended version. So introduce new macros PCI_CONF1_ADDRESS() and PCI_CONF1_EXT_ADDRESS() in include file drivers/pci/pci.h which can be suitable for PCI and PCIe controllers which uses this type of access to PCI config space. Link: https://lore.kernel.org/r/20220924092404.31776-2-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2022-09-21PCI: Sanitise firmware BAR assignments behind a PCI-PCI bridgeMaciej W. Rozycki
When pci_assign_resource() is unable to assign resources to a BAR, it uses pci_revert_fw_address() to fall back to a firmware assignment (if any). Previously pci_revert_fw_address() assumed all addresses could reach the device, but this is not true if the device is below a bridge that only forwards addresses within its windows. This problem was observed on a Tyan Tomcat IV S1564D system where the BIOS did not assign valid addresses to several bridges and USB devices: pci 0000:00:11.0: PCI-to-PCIe bridge to [bus 01-ff] pci 0000:00:11.0: bridge window [io 0xe000-0xefff] pci 0000:01:00.0: PCIe Upstream Port to [bus 02-ff] pci 0000:01:00.0: bridge window [io 0x0000-0x0fff] # unreachable pci 0000:02:02.0: PCIe Downstream Port to [bus 05-ff] pci 0000:02:02.0: bridge window [io 0x0000-0x0fff] # unreachable pci 0000:05:00.0: PCIe-to-PCI bridge to [bus 06-ff] pci 0000:05:00.0: bridge window [io 0x0000-0x0fff] # unreachable pci 0000:06:08.0: USB UHCI 1.1 pci 0000:06:08.0: BAR 4: [io 0xfce0-0xfcff] # unreachable pci 0000:06:08.1: USB UHCI 1.1 pci 0000:06:08.1: BAR 4: [io 0xfce0-0xfcff] # unreachable pci 0000:06:08.0: can't claim BAR 4 [io 0xfce0-0xfcff]: no compatible bridge window pci 0000:06:08.1: can't claim BAR 4 [io 0xfce0-0xfcff]: no compatible bridge window During the first pass of assigning unassigned resources, there was not enough I/O space available, so we couldn't assign the 06:08.0 BAR and reverted to the firmware assignment (still unreachable). Reverting the 06:08.1 assignment failed because it conflicted with 06:08.0: pci 0000:00:11.0: bridge window [io 0xe000-0xefff] pci 0000:01:00.0: no space for bridge window [io size 0x2000] pci 0000:02:02.0: no space for bridge window [io size 0x1000] pci 0000:05:00.0: no space for bridge window [io size 0x1000] pci 0000:06:08.0: BAR 4: no space for [io size 0x0020] pci 0000:06:08.0: BAR 4: trying firmware assignment [io 0xfce0-0xfcff] pci 0000:06:08.1: BAR 4: no space for [io size 0x0020] pci 0000:06:08.1: BAR 4: trying firmware assignment [io 0xfce0-0xfcff] pci 0000:06:08.1: BAR 4: [io 0xfce0-0xfcff] conflicts with 0000:06:08.0 [io 0xfce0-0xfcff] A subsequent pass assigned valid bridge windows and a valid 06:08.1 BAR, but left the 06:08.0 BAR alone, so the UHCI device was still unusable: pci 0000:00:11.0: bridge window [io 0xe000-0xefff] released pci 0000:00:11.0: bridge window [io 0x1000-0x2fff] # reassigned pci 0000:01:00.0: bridge window [io 0x1000-0x2fff] # reassigned pci 0000:02:02.0: bridge window [io 0x2000-0x2fff] # reassigned pci 0000:05:00.0: bridge window [io 0x2000-0x2fff] # reassigned pci 0000:06:08.0: BAR 4: assigned [io 0xfce0-0xfcff] # left alone pci 0000:06:08.1: BAR 4: assigned [io 0x2000-0x201f] ... uhci_hcd 0000:06:08.0: host system error, PCI problems? uhci_hcd 0000:06:08.0: host controller process error, something bad happened! uhci_hcd 0000:06:08.0: host controller halted, very bad! uhci_hcd 0000:06:08.0: HCRESET not completed yet! uhci_hcd 0000:06:08.0: HC died; cleaning up If the address assigned by firmware is not reachable because it's not within upstream bridge windows, fail instead of assigning the unusable address from firmware. [bhelgaas: commit log, use pci_upstream_bridge()] Link: https://bugzilla.kernel.org/show_bug.cgi?id=16263 Link: https://lore.kernel.org/r/alpine.DEB.2.21.2203012338460.46819@angie.orcam.me.uk Link: https://lore.kernel.org/r/alpine.DEB.2.21.2209211921250.29493@angie.orcam.me.uk Fixes: 58c84eda0756 ("PCI: fall back to original BIOS BAR addresses") Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org # v2.6.35+
2022-09-21PCI: Fix typo in pci_scan_child_bus_extend()Mika Westerberg
Should be 'if' not 'of'. Fix this. Link: https://lore.kernel.org/r/20220905080232.36087-7-mika.westerberg@linux.intel.com Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2022-09-21PCI: Fix whitespace and indentationMika Westerberg
Drop two empty lines from pci_scan_child_bus_extend() and correct indentation in pci_bridge_distribute_available_resources() to better follow the kernel coding style. No functional impact. Link: https://lore.kernel.org/r/20220905080232.36087-6-mika.westerberg@linux.intel.com Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2022-09-21PCI: Distribute available resources for root buses, tooMika Westerberg
Previously we distributed spare resources only upon hot-add, so if the initial root bus scan found devices that had not been fully configured by the BIOS, we allocated only enough resources to cover what was then present. If some of those devices were hotplug bridges, we did not leave any additional resource space for future expansion. Distribute the available resources for root buses, too, to make this work the same way as the normal hotplug case. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216000 Link: https://lore.kernel.org/r/20220905080232.36087-5-mika.westerberg@linux.intel.com Reported-by: Chris Chiu <chris.chiu@canonical.com> Tested-by: Chris Chiu <chris.chiu@canonical.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2022-09-21PCI: Move pci_assign_unassigned_root_bus_resources()Mika Westerberg
We need to be able to call pci_bridge_distribute_available_resources() from this function so move it accordingly to avoid need for forward declaration. No functional impact. Link: https://lore.kernel.org/r/20220905080232.36087-4-mika.westerberg@linux.intel.com Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2022-09-21PCI: Pass available buses even if the bridge is already configuredMika Westerberg
If some part of the PCI topology is already configured (by the boot firmware) but not all, and it includes hotplug bridges, we may need to extend the bus resources of those bridges to accommodate any future hotplugs, in the same way we already do with the normal hotplug case. Pass the available buses to pci_scan_child_bus_extend() even when the bridge in question is already configured so the bus allocation code can use these available buses to extend the possible hotplug bridges below. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216000 Link: https://lore.kernel.org/r/20220905080232.36087-3-mika.westerberg@linux.intel.com Reported-by: Chris Chiu <chris.chiu@canonical.com> Tested-by: Chris Chiu <chris.chiu@canonical.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2022-09-20PCI: Fix used_buses calculation in pci_scan_child_bus_extend()Mika Westerberg
pci_scan_bridge_extend() returns the subordinate bus number needed to cover all the buses below a bridge. pci_scan_child_bus_extend() computes the number of buses to reserve by comparing that with the current max bus number. Previously it did the subtraction in the wrong order, so 'used_buses' was nonsense. Subtract 'max' from 'cmax' as is done for the similar pci_scan_bridge_extend() call in the following block. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216000 Fixes: 3374c545c27c ("PCI: Account for all bridges on bus when distributing bus numbers") Link: https://lore.kernel.org/r/20220905080232.36087-2-mika.westerberg@linux.intel.com Reported-by: Chris Chiu <chris.chiu@canonical.com> Tested-by: Chris Chiu <chris.chiu@canonical.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2022-09-19PCI/P2PDMA: Use for_each_pci_dev() helperYang Yingliang
Use for_each_pci_dev() instead of open-coding it. No functional change. Link: https://lore.kernel.org/r/20220916140329.679633-1-yangyingliang@huawei.com Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
2022-09-16PCI: aardvark: Add support for PCI Bridge Subsystem Vendor ID on emulated bridgePali Rohár
Register with Subsystem Device/Vendor ID is at offset 0x2c. Export it via the emulated bridge to enable support for the Subsystem Device/Vendor ID - by reading it in the PCI controller config space and storing it in the emulated bridge control structures, so that it is exposed in the respective PCI capability. After this change Subsystem ID is visible in lspci output at line: Capabilities: [40] Subsystem Link: https://lore.kernel.org/r/20220711225915.13896-1-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
2022-09-14PCI: apple: Do not leak reset GPIO on unbind/unload/errorDmitry Torokhov
The driver allocates reset GPIO in apple_pcie_setup_port() but neither releases the resource, nor uses devm API to have it released automatically. Let's fix this by switching to devm API. While at it let's use generic devm_fwnode_gpiod_get() instead of OF-specific gpiod_get_from_of_node() - this will allow us top stop exporting the latter down the road. Link: https://lore.kernel.org/r/YxatO5OaI2RpxQ2M@google.com Fixes: 1e33888fbe44 ("PCI: apple: Add initial hardware bring-up") Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: Hector Martin <marcan@marcan.st> Acked-by: Marc Zyngier <maz@kernel.org>
2022-09-12PCI/PM: Simplify pci_pm_suspend_noirq()Rajvi Jingar
We always want to save the device state unless the driver has already done it. Rearrange the checking in pci_pm_suspend_noirq() to make this more clear. No functional change intended. [bhelgaas: commit log, rewrap comment] Link: https://lore.kernel.org/r/20220830104913.1620539-1-rajvi.jingar@linux.intel.com Signed-off-by: Rajvi Jingar <rajvi.jingar@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-09-12PCI/PM: Always disable PTM for all devices during suspendBjorn Helgaas
We want to disable PTM on Root Ports because that allows some chips, e.g., Intel mobile chips since Coffee Lake, to enter a lower-power PM state. That means we also have to disable PTM on downstream devices. PCIe r6.0, sec 2.2.8, recommends that functions support generation of messages in non-D0 states, so we have to assume Switch Upstream Ports or Endpoints may send PTM Requests while in D1, D2, and D3hot. A PTM message received by a Downstream Port (including a Root Port) with PTM disabled must be treated as an Unsupported Request (sec 6.21.3). PTM was previously disabled only for Root Ports, and it was disabled in pci_prepare_to_sleep(), which is not called at all if a driver supports legacy PM or does its own state saving. Instead, disable PTM early in pci_pm_suspend() and pci_pm_runtime_suspend() so we do it in all cases. Previously PTM was disabled *after* saving device state, so the state restore on resume automatically re-enabled it. Since we now disable PTM *before* saving state, we must explicitly re-enable it in pci_pm_resume() and pci_pm_runtime_resume(). Here's a sample of errors that occur when PTM is disabled only on the Root Port. With this topology: 0000:00:1d.0 Root Port to [bus 08-71] 0000:08:00.0 Switch Upstream Port to [bus 09-71] Kai-Heng reported errors like this: pcieport 0000:00:1d.0: [20] UnsupReq (First) pcieport 0000:00:1d.0: AER: TLP Header: 34000000 08000052 00000000 00000000 Decoding TLP header 0x34...... (0011 0100b) and 0x08000052: Fmt 001b 4 DW header, no data Type 1 0100b Msg (Local - Terminate at Receiver) Requester ID 0x0800 Bus 08 Devfn 00.0 Message Code 0x52 0101 0010b PTM Request The 00:1d.0 Root Port logged an Unsupported Request error when it received a PTM Request with Requester ID 08:00.0. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215453 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216210 Fixes: a697f072f5da ("PCI: Disable PTM during suspend to save power") Link: https://lore.kernel.org/r/20220909202505.314195-10-helgaas@kernel.org Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by: Rajvi Jingar <rajvi.jingar@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-09-12PCI/PTM: Consolidate PTM interface declarationsBjorn Helgaas
Consolidate all the PTM-related declarations in drivers/pci/pci.h. No functional change intended. Link: https://lore.kernel.org/r/20220909202505.314195-9-helgaas@kernel.org Tested-by: Rajvi Jingar <rajvi.jingar@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-09-12PCI/PTM: Reorder functions in logical orderBjorn Helgaas
pci_enable_ptm() and pci_disable_ptm() were separated. pci_save_ptm_state() and pci_restore_ptm_state() dangled at the top. Move them to logical places. No functional change intended. Link: https://lore.kernel.org/r/20220909202505.314195-8-helgaas@kernel.org Tested-by: Rajvi Jingar <rajvi.jingar@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-09-12PCI/PTM: Preserve RsvdP bits in PTM Control registerBjorn Helgaas
Even though only the low 16 bits of PTM Control are currently defined, the register is 32 bits wide and the unused bits are RsvdP ("Reserved and Preserved"), so software must preserve the values of those bits when writing the register. Update PTM Control reads and writes to use 32-bit accesses and preserve the reserved bits on writes. Link: https://lore.kernel.org/r/20220909202505.314195-7-helgaas@kernel.org Tested-by: Rajvi Jingar <rajvi.jingar@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-09-12PCI/PTM: Move pci_ptm_info() body into its only callerBjorn Helgaas
pci_ptm_info() is simple and is only called by pci_enable_ptm(). Move the entire body there. No functional change intended. Link: https://lore.kernel.org/r/20220909202505.314195-6-helgaas@kernel.org Tested-by: Rajvi Jingar <rajvi.jingar@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-09-12PCI/PTM: Add pci_suspend_ptm() and pci_resume_ptm()Bjorn Helgaas
We disable PTM during suspend because that allows some Root Ports to enter lower-power PM states, which means we also need to disable PTM for all downstream devices. Add pci_suspend_ptm() and pci_resume_ptm() for this purpose. pci_enable_ptm() and pci_disable_ptm() are for drivers to use to enable or disable PTM. They use dev->ptm_enabled to keep track of whether PTM should be enabled. pci_suspend_ptm() and pci_resume_ptm() are PCI core-internal functions to temporarily disable PTM during suspend and (depending on dev->ptm_enabled) re-enable PTM during resume. Enable/disable/suspend/resume all use internal __pci_enable_ptm() and __pci_disable_ptm() functions that only update the PTM Control register. Outline: pci_enable_ptm(struct pci_dev *dev) { __pci_enable_ptm(dev); dev->ptm_enabled = 1; pci_ptm_info(dev); } pci_disable_ptm(struct pci_dev *dev) { if (dev->ptm_enabled) { __pci_disable_ptm(dev); dev->ptm_enabled = 0; } } pci_suspend_ptm(struct pci_dev *dev) { if (dev->ptm_enabled) __pci_disable_ptm(dev); } pci_resume_ptm(struct pci_dev *dev) { if (dev->ptm_enabled) __pci_enable_ptm(dev); } Nothing currently calls pci_resume_ptm(); the suspend path saves the PTM state before disabling PTM, so the PTM state restore in the resume path implicitly re-enables it. A future change will use pci_resume_ptm() to fix some problems with this approach. Link: https://lore.kernel.org/r/20220909202505.314195-5-helgaas@kernel.org Tested-by: Rajvi Jingar <rajvi.jingar@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-09-12PCI/PTM: Separate configuration and enableBjorn Helgaas
PTM configuration and enabling were previously mixed together: pci_ptm_init() collected granularity info and enabled PTM for Root Ports and Switch Upstream Ports; pci_enable_ptm() did the same for Endpoints. Move everything related to the PTM Capability register to pci_ptm_init() for all devices, and everything related to the PTM Control register to pci_enable_ptm(). Link: https://lore.kernel.org/r/20220909202505.314195-4-helgaas@kernel.org Tested-by: Rajvi Jingar <rajvi.jingar@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-09-12PCI/PTM: Add pci_upstream_ptm() helperBjorn Helgaas
PTM requires an unbroken path of PTM-supporting devices between the PTM Root and the ultimate PTM Requester, but if a Switch supports PTM, only the Upstream Port can have a PTM Capability; the Downstream Ports do not. Previously we copied the PTM configuration from the Switch Upstream Port to the Downstream Ports so dev->ptm_enabled for any device implied that all the upstream devices support PTM. Instead of making it look like Downstream Ports have their own PTM config, add pci_upstream_ptm(), which returns the upstream device that has a PTM Capability (either a Root Port or a Switch Upstream Port). Link: https://lore.kernel.org/r/20220909202505.314195-3-helgaas@kernel.org Tested-by: Rajvi Jingar <rajvi.jingar@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-09-12PCI/PTM: Cache PTM Capability offsetBjorn Helgaas
Cache the PTM Capability offset instead of searching for it every time we enable/disable PTM or save/restore PTM state. No functional change intended. Link: https://lore.kernel.org/r/20220909202505.314195-2-helgaas@kernel.org Tested-by: Rajvi Jingar <rajvi.jingar@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-08-30PCI: qcom-ep: Add MODULE_DEVICE_TABLEDmitry Baryshkov
Add MODULE_DEVICE_TABLE to enable module autoloading for respective device. Link: https://lore.kernel.org/r/20220430084740.3769925-1-dmitry.baryshkov@linaro.org Fixes: f55fee56a631 ("PCI: qcom-ep: Add Qualcomm PCIe Endpoint controller driver") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
2022-08-29PCI: dwc: Drop dependency on ZONE_DMA32Will McVicker
Re-work the msi_msg DMA allocation logic to use dmam_alloc_coherent() which uses the coherent DMA mask to try to return an allocation within the DMA mask limits. With that, we now can drop the msi_page parameter in struct dw_pcie_rp. This allows kernel configurations that disable ZONE_DMA32 to continue supporting a 32-bit DMA mask. Without this patch, the PCIe host device will fail to probe when ZONE_DMA32 is disabled. Link: https://lore.kernel.org/r/20220825235404.4132818-2-willmcvicker@google.com Fixes: 35797e672ff0 ("PCI: dwc: Fix MSI msi_msg DMA mapping") Reported-by: Isaac J. Manjarres <isaacmanjarres@google.com> Signed-off-by: Will McVicker <willmcvicker@google.com> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Jingoo Han <jingoohan1@gmail.com>
2022-08-26PCI/MSI: Correct 'can_mask' test in msi_add_msi_desc()Josef Johansson
71020a3c0dff4 ("PCI/MSI: Use msi_add_msi_desc()") inadvertently reversed the sense of "msi_attrib.can_mask" in one use: - if (entry->pci.msi_attrib.can_mask) { - addr = pci_msix_desc_addr(entry); - entry->pci.msix_ctrl = readl(addr + PCI_MSIX_ENTRY_VECTOR_CTRL); + if (!desc.pci.msi_attrib.can_mask) { + addr = pci_msix_desc_addr(&desc); + desc.pci.msix_ctrl = readl(addr + PCI_MSIX_ENTRY_VECTOR_CTRL); Restore the original test. [bhelgaas: commit log] Fixes: 71020a3c0dff4 ("PCI/MSI: Use msi_add_msi_desc()") Link: https://lore.kernel.org/r/d818f9c9-a432-213e-4152-eaff3b7da52e@oderland.se Signed-off-by: Josef Johansson <josef@oderland.se> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
2022-08-25PCI: pci-bridge-emul: Set position of PCI capabilities to real HW valuePali Rohár
mvebu and aardvark HW have PCIe capabilities on different offset in PCI config space. Extend pci-bridge-emul.c code to allow setting custom driver custom value where PCIe capabilities starts. With this change PCIe capabilities of both drivers are reported at the same location as where they are reported by U-Boot - in their real HW offset. Link: https://lore.kernel.org/r/20220824112124.21675-1-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
2022-08-23PCI: mediatek-gen3: Change driver name to mtk-pcie-gen3Felix Fietkau
driver_register() will refuse to register another driver with the same name. This change allows pcie-mediatek-gen3 to coexist with pcie-mediatek built into the kernel. Link: https://lore.kernel.org/r/20220505083907.86598-1-nbd@nbd.name Fixes: d3bf75b579b9 ("PCI: mediatek-gen3: Add MediaTek Gen3 driver for MT8192") Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Jianjun Wang <jianjun.wang@mediatek.com>
2022-08-23PCI: mvebu: Fix endianness when accessing PCI emul bridge membersPali Rohár
PCI emul bridge members iolimitupper, iobaseupper, memlimit and membase are of type __le16, so correctly access these members using le16_to_cpu() macros. Link: https://lore.kernel.org/r/20220812141115.24082-1-pali@kernel.org Fixes: e7a01876729c ("PCI: mvebu: Propagate errors when updating PCI_IO_BASE and PCI_MEM_BASE registers") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
2022-08-23PCI: qcom: Sort device-id tableJohan Hovold
Sort the device-id table entries alphabetically by compatible string to make it easier to find entries and add new ones. Link: https://lore.kernel.org/r/20220714071348.6792-9-johan+linaro@kernel.org Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: Brian Masney <bmasney@redhat.com> Acked-by: Stanimir Varbanov <svarbanov@mm-sol.com>
2022-08-23PCI: qcom: Clean up IP configurationsJohan Hovold
The various IP versions have different configurations that are encoded in separate sets of operation callbacks. Currently, there is no need for also maintaining corresponding sets of data parameters, but it is conceivable that these may again be found useful (e.g. to implement minor variations of the operation callbacks). Rename the default configuration structures after the IP version they apply to so that they can more easily be reused by different SoCs. Note that SoC specific configurations can be added later if need arises (e.g. cfg_sc8280xp). Link: https://lore.kernel.org/r/20220714071348.6792-8-johan+linaro@kernel.org Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Brian Masney <bmasney@redhat.com> Acked-by: Stanimir Varbanov <svarbanov@mm-sol.com>
2022-08-23PCI: qcom: Make all optional clocks optionalJohan Hovold
The kernel is not a devicetree validator and does not need to re-encode information which is already available in the devicetree. This is specifically true for the optional PCIe clocks, some of which are really interconnect clocks. Treat also the 2.7.0 optional clocks as truly optional instead of maintaining a list of clocks per compatible (including two compatible strings for the two identical controllers on sm8450) just to validate the devicetree. Link: https://lore.kernel.org/r/20220714071348.6792-7-johan+linaro@kernel.org Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Brian Masney <bmasney@redhat.com> Acked-by: Stanimir Varbanov <svarbanov@mm-sol.com>
generated by cgit (git 2.34.1) at 2025-09-12 00:18:24 +0000