aboutsummaryrefslogtreecommitdiff
path: root/drivers/pci
AgeCommit message (Collapse)AuthorFilesLines
2022-10-04PCI/ASPM: Save L1 PM Substates Capability for suspend/resumeVidya Sagar3-0/+48
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/[email protected] Signed-off-by: Vidya Sagar <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2022-10-04PCI/ASPM: Refactor L1 PM Substates Control Register programmingVidya Sagar1-34/+40
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/[email protected]] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vidya Sagar <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2022-10-04xen-pcifront: Handle missed Connected stateJason Andryuk1-2/+16
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 <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]>
2022-10-03PCI: qcom-ep: Make use of the cached dev pointerManivannan Sadhasivam1-2/+2
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/[email protected] Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]>
2022-10-03PCI: qcom-ep: Rely on the clocks supplied by devicetreeManivannan Sadhasivam1-20/+13
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/[email protected] Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]>
2022-10-03PCI: qcom-ep: Add kernel-doc for qcom_pcie_ep structureManivannan Sadhasivam1-0/+17
Add kernel-doc for qcom_pcie_ep structure. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]>
2022-10-03phy: freescale: imx8m-pcie: Fix the wrong order of phy_init() and phy_power_on()Richard Zhu1-3/+3
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/[email protected] Fixes: 1aa97b002258 ("phy: freescale: pcie: Initialize the imx8 pcie standalone phy driver") Tested-by: Alexander Stein <[email protected]> Signed-off-by: Richard Zhu <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Vinod Koul <[email protected]> Acked-by: Lorenzo Pieralisi <[email protected]>
2022-10-03PCI: imx6: Add i.MX8MP PCIe supportRichard Zhu1-2/+25
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/[email protected] Tested-by: Marek Vasut <[email protected]> Tested-by: Richard Leitner <[email protected]> Tested-by: Alexander Stein <[email protected]> Signed-off-by: Richard Zhu <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Lucas Stach <[email protected]>
2022-10-03PCI: dwc: Replace of_gpio_named_count() by gpiod_count()Andy Shevchenko1-2/+2
As a preparation to unexport of_gpio_named_count(), convert the driver to use gpiod_count() instead. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Rob Herring <[email protected]>
2022-09-29PCI/PM: Reduce D3hot delay with usleep_range()Sajid Dalvi1-7/+9
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/[email protected] Signed-off-by: Sajid Dalvi <[email protected]> Signed-off-by: Will McVicker <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Matthias Kaehlcke <[email protected]>
2022-09-29PCI: tegra: Use PCI_CONF1_EXT_ADDRESS() macroPali Rohár1-8/+3
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/[email protected] Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Thierry Reding <[email protected]>
2022-09-29PCI: qcom: Rename host-init error labelJohan Hovold1-2/+2
Use a more descriptive name for the reset host-init error label for consistency. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]>
2022-09-29PCI: qcom: Drop unused post_deinit callbackJohan Hovold1-3/+0
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/[email protected] Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]>
2022-09-27PCI/DPC: Quirk PIO log size for certain Intel Root PortsMika Westerberg2-5/+46
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/[email protected] Signed-off-by: Mika Westerberg <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Kuppuswamy Sathyanarayanan <[email protected]>
2022-09-27PCI: mt7621: Use PCI_CONF1_EXT_ADDRESS() macroPali Rohár1-11/+6
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/[email protected] Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Sergio Paracuellos <[email protected]>
2022-09-27PCI: ftpci100: Use PCI_CONF1_ADDRESS() macroPali Rohár1-17/+4
Simplify pci-ftpci100.c driver code and use new PCI_CONF1_ADDRESS() macro for accessing PCI config space. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]>
2022-09-27PCI: Add standard PCI Config Address macrosPali Rohár1-0/+45
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/[email protected] Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Bjorn Helgaas <[email protected]>
2022-09-21PCI: Sanitise firmware BAR assignments behind a PCI-PCI bridgeMaciej W. Rozycki1-0/+11
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/[email protected] Link: https://lore.kernel.org/r/[email protected] Fixes: 58c84eda0756 ("PCI: fall back to original BIOS BAR addresses") Signed-off-by: Maciej W. Rozycki <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Cc: [email protected] # v2.6.35+
2022-09-21PCI: Fix typo in pci_scan_child_bus_extend()Mika Westerberg1-1/+1
Should be 'if' not 'of'. Fix this. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mika Westerberg <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]>
2022-09-21PCI: Fix whitespace and indentationMika Westerberg2-3/+1
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/[email protected] Signed-off-by: Mika Westerberg <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]>
2022-09-21PCI: Distribute available resources for root buses, tooMika Westerberg1-1/+61
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/[email protected] Reported-by: Chris Chiu <[email protected]> Tested-by: Chris Chiu <[email protected]> Signed-off-by: Mika Westerberg <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]>
2022-09-21PCI: Move pci_assign_unassigned_root_bus_resources()Mika Westerberg1-113/+113
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/[email protected] Signed-off-by: Mika Westerberg <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]>
2022-09-21PCI: Pass available buses even if the bridge is already configuredMika Westerberg1-2/+3
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/[email protected] Reported-by: Chris Chiu <[email protected]> Tested-by: Chris Chiu <[email protected]> Signed-off-by: Mika Westerberg <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]>
2022-09-20PCI: Fix used_buses calculation in pci_scan_child_bus_extend()Mika Westerberg1-2/+2
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/[email protected] Reported-by: Chris Chiu <[email protected]> Tested-by: Chris Chiu <[email protected]> Signed-off-by: Mika Westerberg <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]>
2022-09-19PCI/P2PDMA: Use for_each_pci_dev() helperYang Yingliang1-1/+1
Use for_each_pci_dev() instead of open-coding it. No functional change. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Yang Yingliang <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Logan Gunthorpe <[email protected]>
2022-09-16PCI: aardvark: Add support for PCI Bridge Subsystem Vendor ID on emulated bridgePali Rohár1-0/+3
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/[email protected] Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]>
2022-09-14PCI: apple: Do not leak reset GPIO on unbind/unload/errorDmitry Torokhov1-2/+2
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/[email protected] Fixes: 1e33888fbe44 ("PCI: apple: Add initial hardware bring-up") Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Hector Martin <[email protected]> Acked-by: Marc Zyngier <[email protected]>
2022-09-12PCI/PM: Simplify pci_pm_suspend_noirq()Rajvi Jingar1-12/+7
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/[email protected] Signed-off-by: Rajvi Jingar <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Rafael J. Wysocki <[email protected]>
2022-09-12PCI/PM: Always disable PTM for all devices during suspendBjorn Helgaas2-26/+13
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/[email protected] Reported-by: Kai-Heng Feng <[email protected]> Tested-by: Rajvi Jingar <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Mika Westerberg <[email protected]>
2022-09-12PCI/PTM: Consolidate PTM interface declarationsBjorn Helgaas1-6/+2
Consolidate all the PTM-related declarations in drivers/pci/pci.h. No functional change intended. Link: https://lore.kernel.org/r/[email protected] Tested-by: Rajvi Jingar <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Mika Westerberg <[email protected]>
2022-09-12PCI/PTM: Reorder functions in logical orderBjorn Helgaas1-62/+62
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/[email protected] Tested-by: Rajvi Jingar <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Mika Westerberg <[email protected]>
2022-09-12PCI/PTM: Preserve RsvdP bits in PTM Control registerBjorn Helgaas1-11/+14
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/[email protected] Tested-by: Rajvi Jingar <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Kuppuswamy Sathyanarayanan <[email protected]> Reviewed-by: Mika Westerberg <[email protected]>
2022-09-12PCI/PTM: Move pci_ptm_info() body into its only callerBjorn Helgaas1-21/+17
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/[email protected] Tested-by: Rajvi Jingar <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Kuppuswamy Sathyanarayanan <[email protected]> Reviewed-by: Mika Westerberg <[email protected]>
2022-09-12PCI/PTM: Add pci_suspend_ptm() and pci_resume_ptm()Bjorn Helgaas3-18/+63
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/[email protected] Tested-by: Rajvi Jingar <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Mika Westerberg <[email protected]>
2022-09-12PCI/PTM: Separate configuration and enableBjorn Helgaas1-55/+49
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/[email protected] Tested-by: Rajvi Jingar <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Mika Westerberg <[email protected]>
2022-09-12PCI/PTM: Add pci_upstream_ptm() helperBjorn Helgaas1-14/+25
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/[email protected] Tested-by: Rajvi Jingar <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Kuppuswamy Sathyanarayanan <[email protected]> Reviewed-by: Mika Westerberg <[email protected]>
2022-09-12PCI/PTM: Cache PTM Capability offsetBjorn Helgaas1-24/+17
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/[email protected] Tested-by: Rajvi Jingar <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Kuppuswamy Sathyanarayanan <[email protected]> Reviewed-by: Mika Westerberg <[email protected]>
2022-08-30PCI: qcom-ep: Add MODULE_DEVICE_TABLEDmitry Baryshkov1-0/+1
Add MODULE_DEVICE_TABLE to enable module autoloading for respective device. Link: https://lore.kernel.org/r/[email protected] Fixes: f55fee56a631 ("PCI: qcom-ep: Add Qualcomm PCIe Endpoint controller driver") Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]>
2022-08-29PCI: dwc: Drop dependency on ZONE_DMA32Will McVicker2-22/+7
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/[email protected] Fixes: 35797e672ff0 ("PCI: dwc: Fix MSI msi_msg DMA mapping") Reported-by: Isaac J. Manjarres <[email protected]> Signed-off-by: Will McVicker <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Rob Herring <[email protected]> Acked-by: Jingoo Han <[email protected]>
2022-08-26PCI/MSI: Correct 'can_mask' test in msi_add_msi_desc()Josef Johansson1-1/+1
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/[email protected] Signed-off-by: Josef Johansson <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]>
2022-08-25PCI: pci-bridge-emul: Set position of PCI capabilities to real HW valuePali Rohár4-17/+35
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/[email protected] Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]>
2022-08-23PCI: mediatek-gen3: Change driver name to mtk-pcie-gen3Felix Fietkau1-1/+1
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/[email protected] Fixes: d3bf75b579b9 ("PCI: mediatek-gen3: Add MediaTek Gen3 driver for MT8192") Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Jianjun Wang <[email protected]>
2022-08-23PCI: mvebu: Fix endianness when accessing PCI emul bridge membersPali Rohár1-6/+6
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/[email protected] Fixes: e7a01876729c ("PCI: mvebu: Propagate errors when updating PCI_IO_BASE and PCI_MEM_BASE registers") Reported-by: kernel test robot <[email protected]> Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]>
2022-08-23PCI: qcom: Sort device-id tableJohan Hovold1-7/+7
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/[email protected] Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Brian Masney <[email protected]> Acked-by: Stanimir Varbanov <[email protected]>
2022-08-23PCI: qcom: Clean up IP configurationsJohan Hovold1-60/+29
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/[email protected] Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Rob Herring <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Brian Masney <[email protected]> Acked-by: Stanimir Varbanov <[email protected]>
2022-08-23PCI: qcom: Make all optional clocks optionalJohan Hovold1-24/+4
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/[email protected] Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Rob Herring <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Brian Masney <[email protected]> Acked-by: Stanimir Varbanov <[email protected]>
2022-08-23PCI: qcom: Add support for SA8540PJohan Hovold1-0/+6
The SA8540P platform has five PCIe controllers: two 4-lane, two 2-lane and one 1-lane. Add a new "qcom,pcie-sa8540p" compatible string and reuse the 1.9.0 ops. Note that like for SC8280XP, the SA8540P controllers need two or three interconnect clocks to be enabled. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Rob Herring <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Brian Masney <[email protected]> Acked-by: Stanimir Varbanov <[email protected]>
2022-08-23PCI: qcom: Add support for SC8280XPJohan Hovold1-2/+20
The SC8280XP platform has seven PCIe controllers: two used with USB4, two 4-lane, two 2-lane and one 1-lane. Add a new "qcom,pcie-sc8280xp" compatible string and reuse the 1.9.0 ops. Note that the SC8280XP controllers need two or three interconnect clocks to be enabled. Model these as optional clocks to avoid encoding devicetree data in the PCIe driver. Note that the same could be done for the SM8450 interconnect clocks and possibly also for the TBU clocks. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Acked-by: Stanimir Varbanov <[email protected]>
2022-08-15arm64: bcmbca: Make BCM4908 drivers depend on ARCH_BCMBCAWilliam Zhang1-1/+1
With Broadcom Broadband arch ARCH_BCMBCA supported in the kernel, this patch series migrate the ARCH_BCM4908 symbol to ARCH_BCMBCA. Hence replace ARCH_BCM4908 with ARCH_BCMBCA in subsystem Kconfig files. Signed-off-by: William Zhang <[email protected]> Acked-by: Guenter Roeck <[email protected]> (for watchdog) Acked-by: Bjorn Helgaas <[email protected]> (for drivers/pci) Acked-by: Wolfram Sang <[email protected]> (for i2c) Acked-by: Philipp Zabel <[email protected]> (for reset) Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Florian Fainelli <[email protected]>
2022-08-13Merge tag 'ntb-5.20' of https://github.com/jonmason/ntbLinus Torvalds4-1/+1464
Pull NTB updates from Jon Mason: "Non-Transparent Bridge updates. Fix of heap data and clang warnings, support for a new Intel NTB device, and NTB EndPoint Function (EPF) support and the various fixes for that" * tag 'ntb-5.20' of https://github.com/jonmason/ntb: MAINTAINERS: add PCI Endpoint NTB drivers to NTB files NTB: EPF: Tidy up some bounds checks NTB: EPF: Fix error code in epf_ntb_bind() PCI: endpoint: pci-epf-vntb: reduce several globals to statics PCI: endpoint: pci-epf-vntb: fix error handle in epf_ntb_mw_bar_init() PCI: endpoint: Fix Kconfig dependency NTB: EPF: set pointer addr to null using NULL rather than 0 Documentation: PCI: extend subheading underline for "lspci output" section Documentation: PCI: Use code-block block for scratchpad registers diagram Documentation: PCI: Add specification for the PCI vNTB function device PCI: endpoint: Support NTB transfer between RC and EP NTB: epf: Allow more flexibility in the memory BAR map method PCI: designware-ep: Allow pci_epc_set_bar() update inbound map address ntb: intel: add GNR support for Intel PCIe gen5 NTB NTB: ntb_tool: uninitialized heap data in tool_fn_write() ntb: idt: fix clang -Wformat warnings
Powered by cgit, Gruvboxed by Blaster4385.