- Fall back to allocating 64-bit MSI DMA address if unable to allocate a
32-bit address (Ajay Agarwal)
* pci/controller/dwc:
PCI: dwc: endpoint: Fix advertised resizable BAR size
PCI: dwc: Strengthen the MSI address allocation logic
- Clear the ARI Capability Next Function Number of the last function
(Jasko-EXT Wojciech)
* pci/controller/cadence:
PCI: cadence: Clear the ARI Capability Next Function Number of the last function
- Fix polling for MDIO write completion, which previously used the wrong
access width so it always indicated "completed" (Jonathan Bell)
* pci/controller/broadcom:
PCI: brcmstb: Fix broken brcm_pcie_mdio_write() polling
- Make pci_epf_bus_type const (Ricardo B. Marliere)
- Update pci_epf_alloc_space() interface and move bar_fixed_size[] testing
from pci_epf_test_alloc_space() and pci_epf_configure_bar() into it
(Niklas Cassel)
- Drop redundant size & alignment checking from epf_ntb_db_bar_init() since
pci_epf_alloc_space() already does it (Niklas Cassel)
- Fix ntb_register_device() name leak in error path (Yang Yingliang)
- Return actual error code for pci_vntb_probe() failure (Yang Yingliang)
- Prefix sysfs function names with "pci_epf_mhi_", e.g.,
"/sys/kernel/config/functions/pci_epf_mhi_sdx55", to leave room for other
endpoint functions (Manivannan Sadhasivam)
- Add EPF MHI support for SA8775P SoC (Mrinmay Sarkar)
- Consolidate endpoint BAR hardware description in new struct
pci_epc_bar_desc (Niklas Cassel)
- Drop only_64bit on reserved BARs (Niklas Cassel)
* pci/endpoint:
PCI: endpoint: Drop only_64bit on reserved BARs
PCI: endpoint: Clean up hardware description for BARs
PCI: epf-mhi: Add support for SA8775P SoC
PCI: epf-mhi: Add "pci_epf_mhi_" prefix to the function names
PCI: epf-vntb: Return actual error code during pci_vntb_probe() failure
NTB: fix possible name leak in ntb_register_device()
PCI: endpoint: pci-epf-vntb: Remove superfluous checks for pci_epf_alloc_space() API
PCI: endpoint: pci-epf-test: Remove superfluous checks for pci_epf_alloc_space() API
PCI: endpoint: Improve pci_epf_alloc_space() API
PCI: endpoint: Refactor pci_epf_alloc_space() API
PCI: endpoint: Make pci_epf_bus_type const
- Avoid Secondary Bus Reset on the LSI / Agere FW643, which allows it to be
assigned to VMs with VFIO, at the cost of leaking FW643 state between VMs
(Edmund Raile)
* pci/virtualization:
PCI: Mark LSI FW643 to avoid bus reset
- Compile pci-sysfs.c only if CONFIG_SYSFS=y, which reduces kernel size by
~120KB when it's disabled (Lukas Wunner)
- Remove obsolete pci_cleanup_rom() declaration (Lukas Wunner)
- Rework pci_dev_resource_resize_attr(n) macros to call a function instead
of duplicating most of the body, which saves about 2.5KB of text (Ilpo
Järvinen)
* pci/sysfs:
PCI/sysfs: Demacrofy pci_dev_resource_resize_attr(n) functions
PCI: Remove obsolete pci_cleanup_rom() declaration
PCI/sysfs: Compile pci-sysfs.c only if CONFIG_SYSFS=y
# Conflicts:
# drivers/pci/Makefile
- Disable use of D3cold on Asus B1400 PCI-NVMe bridges because some BIOSes
can't power them back on, replacing a more general ACPI sleep quirk
(Daniel Drake)
- Allow runtime PM when the driver enables it but doesn't need any runtime
PM callbacks (Raag Jadav)
- Drain runtime-idle callbacks before driver removal to avoid races between
.remove() and .runtime_idle(), which caused intermittent page faults when
the rtsx .runtime_idle() accessed registers that its .remove() had
already unmapped (Rafael J. Wysocki)
* pci/pm:
PCI/PM: Drain runtime-idle callbacks before driver removal
PCI/PM: Allow runtime PM with no PM callbacks at all
Revert "ACPI: PM: Block ASUS B1400CEAE from suspend to idle by default"
PCI: Disable D3cold on Asus B1400 PCI-NVMe bridge
- Collect interrupt-related code in irq.c (Ilpo Järvinen)
- Mark 3ware-9650SE Root Port Extended Tags as broken (Jörg Wedekind)
* pci/enumeration:
PCI: Mark 3ware-9650SE Root Port Extended Tags as broken
PCI: Place interrupt related code into irq.c
# Conflicts:
# drivers/pci/Makefile
- After a DPC event, print all logged TLP Prefixes instead of printing the
first prefix several times (Ilpo Järvinen)
- Ignore the expected Surprise Down error that may cause a DPC event when
hot-removing a device (Smita Koralahalli)
- Add an RP PIO log size quirk for Intel Raptor Lake Root Ports, which
still don't advertise the correct log size, which prevented logging of RP
PIO Log registers when DPC is triggered (Paul Menzel)
* pci/dpc:
PCI/DPC: Quirk PIO log size for Intel Raptor Lake Root Ports
PCI/DPC: Ignore Surprise Down error on hot removal
PCI/DPC: Print all TLP Prefixes, not just the first
- Unmap MMIO mappings in pci_iounmap() to avoid a leak when
ARCH_HAS_GENERIC_IOPORT_MAP is defined (Philipp Stanner)
- Move pci_iomap.c to drivers/pci/ since it's all PCI-related (Philipp
Stanner)
- Move other PCI-related devres code from lib/devres.c to drivers/pci/
(Philipp Stanner)
- Move other devres code from pci.c to devres.c (Philipp Stanner)
* pci/devres:
PCI: Move devres code from pci.c to devres.c
PCI: Move PCI-specific devres code to drivers/pci/
PCI: Move pci_iomap.c to drivers/pci/
pci_iounmap(): Fix MMIO mapping leak
- Collect ASPM-related code into aspm.c (David E. Box)
- Save and restore ASPM L1 PM Substates configuration so these states
continue working after suspend/resume (David E. Box)
- Move the ASPM L1.2-related LTR save/restore next to the ASPM save/restore
(David E. Box)
- Move the required L1 disable before L1 Substate configuration into
pci_restore_aspm_l1ss_state() (Bjorn Helgaas)
- Update save_save when ASPM config is changed, so a .slot_reset() during
error recovery restores the changed config, not the .probe()-time config
(Vidya Sagar)
* pci/aspm:
PCI/ASPM: Update save_state when configuration changes
PCI/ASPM: Disable L1 before configuring L1 Substates
PCI/ASPM: Call pci_save_ltr_state() from pci_save_pcie_state()
PCI/ASPM: Save L1 PM Substates Capability for suspend/resume
PCI/ASPM: Move pci_save_ltr_state() to aspm.c
PCI/ASPM: Always build aspm.c
PCI/ASPM: Move pci_configure_ltr() to aspm.c
Many PCIe device drivers save the configuration state of their device
during probe and restore it when their .slot_reset() hook is called during
PCIe error recovery.
If the ASPM configuration is changed after the driver's probe is called and
before an error event occurs, .slot_reset() restores the ASPM configuration
to what it was at the time of probe, not to what it was just before the
occurrence of the error event. This leads to a mismatch in ASPM
configuration between the device and its upstream device.
Update the saved configuration of the device when the ASPM configuration
changes.
Link: https://lore.kernel.org/r/20240222174436.3565146-1-vidyas@nvidia.com
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
[bhelgaas: commit log, rebase to pci/aspm, rename to
pci_update_aspm_saved_state() since it updates only LNKCTL, update only
ASPMC and CLKREQ_EN in LNKCTL]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Reviewed-by: David E. Box <david.e.box@linux.intel.com>
Per PCIe r6.1, sec 5.5.4, L1 must be disabled while setting ASPM L1 PM
Substates enable bits. Previously this was enforced by clearing
PCI_EXP_LNKCTL_ASPMC before calling pci_restore_aspm_l1ss_state().
Move the L1 (and L0s, although that doesn't seem required) disable into
pci_restore_aspm_l1ss_state() itself so it's closer to the code that
depends on it.
Link: https://lore.kernel.org/r/20240223213733.GA115410@bhelgaas
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
4ff116d0d5 ("PCI/ASPM: Save L1 PM Substates Capability for
suspend/resume") restored the L1 PM Substates Capability after resume,
which reduced power consumption by making the ASPM L1.x states work after
resume.
a7152be79b ("Revert "PCI/ASPM: Save L1 PM Substates Capability for
suspend/resume"") reverted 4ff116d0d5 because resume failed on some
systems, so power consumption after resume increased again.
a7152be79b mentioned that we restore L1 PM substate configuration even
though ASPM L1 may already be enabled. This is due the fact that the
pci_restore_aspm_l1ss_state() was called before pci_restore_pcie_state().
Save and restore the L1 PM Substates Capability, following PCIe r6.1, sec
5.5.4 more closely by:
1) Do not restore ASPM configuration in pci_restore_pcie_state() but
do that after PCIe capability is restored in pci_restore_aspm_state()
following PCIe r6.1, sec 5.5.4.
2) If BIOS reenables L1SS, particularly L1.2, we need to clear the
enables in the right order, downstream before upstream. Defer
restoring the L1SS config until we are at the downstream component.
Then update the config for both ends of the link in the prescribed
order.
3) Program ASPM L1 PM substate configuration before L1 enables.
4) Program ASPM L1 PM substate enables last, after rest of the fields
in the capability are programmed.
[bhelgaas: commit log, squash L1SS-related patches, do both LNKCTL restores
in pci_restore_pcie_state()]
Link: https://lore.kernel.org/r/20240128233212.1139663-3-david.e.box@linux.intel.com
Link: https://lore.kernel.org/r/20240128233212.1139663-4-david.e.box@linux.intel.com
Link: https://lore.kernel.org/r/20240223205851.114931-5-helgaas@kernel.org
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217321
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216782
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216877
Co-developed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Co-developed-by: David E. Box <david.e.box@linux.intel.com>
Reported-by: Koba Ko <koba.ko@canonical.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Tasev Nikola <tasev.stefanoska@skynet.be> # Asus UX305FA
Cc: Mark Enriquez <enriquezmark36@gmail.com>
Cc: Thomas Witt <kernel@witt.link>
Cc: Werner Sembach <wse@tuxedocomputers.com>
Cc: Vidya Sagar <vidyas@nvidia.com>
The commit message in commit fc9a77040b ("PCI: designware-ep: Configure
Resizable BAR cap to advertise the smallest size") claims that it modifies
the Resizable BAR capability to only advertise support for 1 MB size BARs.
However, the commit writes all zeroes to PCI_REBAR_CAP (the register which
contains the possible BAR sizes that a BAR be resized to).
According to the spec, it is illegal to not have a bit set in
PCI_REBAR_CAP, and 1 MB is the smallest size allowed.
Set bit 4 in PCI_REBAR_CAP, so that we actually advertise support for a
1 MB BAR size.
Before:
Capabilities: [2e8 v1] Physical Resizable BAR
BAR 0: current size: 1MB
BAR 1: current size: 1MB
BAR 2: current size: 1MB
BAR 3: current size: 1MB
BAR 4: current size: 1MB
BAR 5: current size: 1MB
After:
Capabilities: [2e8 v1] Physical Resizable BAR
BAR 0: current size: 1MB, supported: 1MB
BAR 1: current size: 1MB, supported: 1MB
BAR 2: current size: 1MB, supported: 1MB
BAR 3: current size: 1MB, supported: 1MB
BAR 4: current size: 1MB, supported: 1MB
BAR 5: current size: 1MB, supported: 1MB
Fixes: fc9a77040b ("PCI: designware-ep: Configure Resizable BAR cap to advertise the smallest size")
Link: https://lore.kernel.org/linux-pci/20240307111520.3303774-1-cassel@kernel.org
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: <stable@vger.kernel.org> # 5.2
Next Function Number field in ARI Capability Register for last function
must be zero by default as per the PCIe specification, indicating there
is no next higher number function but that's not happening in our case,
so this patch clears the Next Function Number field for last function
used.
[kwilczynski: white spaces update for one define]
Link: https://lore.kernel.org/linux-pci/20231202085015.3048516-1-s-vadapalli@ti.com
Signed-off-by: Jasko-EXT Wojciech <wojciech.jasko-EXT@continental-corporation.com>
Signed-off-by: Achal Verma <a-verma1@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
There can be platforms that do not use/have 32-bit DMA addresses.
The current implementation of 32-bit IOVA allocation can fail for
such platforms, eventually leading to the probe failure.
Try to allocate a 32-bit msi_data. If this allocation fails,
attempt a 64-bit address allocation. Please note that if the
64-bit MSI address is allocated, then the EPs supporting 32-bit
MSI address only will not work.
Link: https://lore.kernel.org/linux-pci/20240221153840.1789979-1-ajayagarwal@google.com
Tested-by: Will McVicker <willmcvicker@google.com>
Signed-off-by: Ajay Agarwal <ajayagarwal@google.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Reviewed-by: Will McVicker <willmcvicker@google.com>
The MDIO_WT_DONE() macro tests bit 31, which is always 0 (== done) as
readw_poll_timeout_atomic() does a 16-bit read. Replace with the readl
variant.
[kwilczynski: commit log]
Fixes: ca5dcc7631 ("PCI: brcmstb: Replace status loops with read_poll_timeout_atomic()")
Link: https://lore.kernel.org/linux-pci/20240217133722.14391-1-wahrenst@gmx.net
Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
Both AER and DPC RP PIO provide TLP Header Log registers (PCIe r6.1 secs
7.8.4 & 7.9.14) to convey error diagnostics but the struct is named after
AER as the struct aer_header_log_regs. Also, not all places that handle TLP
Header Log use the struct and the struct members are named individually.
Generalize the struct name and members, and use it consistently where TLP
Header Log is being handled so that a pcie_read_tlp_log() helper can be
easily added.
Link: https://lore.kernel.org/r/20240206135717.8565-3-ilpo.jarvinen@linux.intel.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
[bhelgaas: drop ixgbe changes for now, tidy whitespace]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Use u32 for PCIe AER Capability register variable and name it "aercc"
(Advanced Error Capabilities and Control register, PCIe r6.1 sec 7.8.4.7)
instead of "temp".
Link: https://lore.kernel.org/r/20240206135717.8565-2-ilpo.jarvinen@linux.intel.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
[bhelgaas: make subject more specific and match similar previous patches]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
PM runtime can be done simultaneously with AER error handling. Avoid that
by using pm_runtime_get_sync() before and pm_runtime_put() after reset in
pcie_do_recovery() for all recovering devices.
pm_runtime_get_sync() will increase dev->power.usage_count counter to
prevent any possible future request to runtime suspend a device. It will
also resume a device, if it was previously in D3hot state.
I tested with igc device by doing simultaneous aer_inject and rpm
suspend/resume via /sys/bus/pci/devices/PCI_ID/power/control and can
reproduce:
igc 0000:02:00.0: not ready 65535ms after bus reset; giving up
pcieport 0000:00:1c.2: AER: Root Port link has been reset (-25)
pcieport 0000:00:1c.2: AER: subordinate device reset failed
pcieport 0000:00:1c.2: AER: device recovery failed
igc 0000:02:00.0: Unable to change power state from D3hot to D0, device inaccessible
The problem disappears when this patch is applied.
Link: https://lore.kernel.org/r/20240212120135.146068-1-stanislaw.gruszka@linux.intel.com
Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Cc: <stable@vger.kernel.org>
Even when CONFIG_PCIEASPM is not set, we save and restore the LTR
Capability so that if ASPM L1.2 and LTR were configured by the platform,
ASPM L1.2 will still work after suspend/resume, when that platform
configuration may be lost. See dbbfadf231 ("PCI/ASPM: Save LTR Capability
for suspend/resume").
Since ASPM L1.2 depends on the LTR Capability, move the save/restore code
to the part of aspm.c that is always compiled regardless of
CONFIG_PCIEASPM. No functional change intended.
Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20240128233212.1139663-5-david.e.box@linux.intel.com
[bhelgaas: commit log, reorder to make this a pure move]
Link: https://lore.kernel.org/r/20240223205851.114931-4-helgaas@kernel.org
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The Latency Tolerance Reporting (LTR) mechanism supports the ASPM L1.2
state and is only configured when CONFIG_PCIEASPM is set.
Move pci_configure_ltr() and pci_bridge_reconfigure_ltr() into aspm.c since
they only build when CONFIG_PCIEASPM is set. No functional change
intended.
Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20240128233212.1139663-2-david.e.box@linux.intel.com
[bhelgaas: commit log, split build change from function moves]
Link: https://lore.kernel.org/r/20240223205851.114931-2-helgaas@kernel.org
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
pci_dev_resource_resize_attr(n) macro is invoked for six resources,
creating a large footprint function for each resource.
Rework the macro to only create a function that calls a helper function so
the compiler can decide if it warrants to inline the function or not.
With x86_64 defconfig, this saves roughly 2.5kB:
$ scripts/bloat-o-meter drivers/pci/pci-sysfs.o{.old,.new}
add/remove: 1/0 grow/shrink: 0/6 up/down: 512/-2934 (-2422)
Function old new delta
__resource_resize_store - 512 +512
resource5_resize_store 503 14 -489
resource4_resize_store 503 14 -489
resource3_resize_store 503 14 -489
resource2_resize_store 503 14 -489
resource1_resize_store 503 14 -489
resource0_resize_store 500 11 -489
Total: Before=13399, After=10977, chg -18.08%
(The compiler seemingly chose to still inline __resource_resize_show()
which is fine, those functions are not very complex/large.)
Link: https://lore.kernel.org/r/20240222114607.1837-1-ilpo.jarvinen@linux.intel.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
It is possible to enable CONFIG_PCI but disable CONFIG_SYSFS and for
space-constrained devices such as routers, such a configuration may
actually make sense.
However pci-sysfs.c is compiled even if CONFIG_SYSFS is disabled,
unnecessarily increasing the kernel's size.
To rectify that:
* Move pci_mmap_fits() to mmap.c. It is not only needed by
pci-sysfs.c, but also proc.c.
* Move pci_dev_type to probe.c and make it private. It references
pci_dev_attr_groups in pci-sysfs.c. Make that public instead for
consistency with pci_dev_groups, pcibus_groups and pci_bus_groups,
which are likewise public and referenced by struct definitions in
pci-driver.c and probe.c.
* Define pci_dev_groups, pci_dev_attr_groups, pcibus_groups and
pci_bus_groups to NULL if CONFIG_SYSFS is disabled. Provide empty
static inlines for pci_{create,remove}_legacy_files() and
pci_{create,remove}_sysfs_dev_files().
Result:
vmlinux size is reduced by 122996 bytes in my arm 32-bit test build.
Link: https://lore.kernel.org/r/85ca95ae8e4d57ccf082c5c069b8b21eb141846e.1698668982.git.lukas@wunner.de
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Commit 5459c0b704 ("PCI/DPC: Quirk PIO log size for certain Intel Root
Ports") and commit 3b8803494a ("PCI/DPC: Quirk PIO log size for Intel Ice
Lake Root Ports") add quirks for Ice, Tiger and Alder Lake Root Ports.
System firmware for Raptor Lake still has the bug, so Linux logs the
warning below on several Raptor Lake systems like Dell Precision 3581 with
Intel Raptor Lake processor (0W18NX) system firmware/BIOS version 1.10.1.
pci 0000:00:07.0: [8086:a76e] type 01 class 0x060400
pci 0000:00:07.0: DPC: RP PIO log size 0 is invalid
pci 0000:00:07.1: [8086:a73f] type 01 class 0x060400
pci 0000:00:07.1: DPC: RP PIO log size 0 is invalid
Apply the quirk for Raptor Lake Root Ports as well.
This also enables the DPC driver to dump the RP PIO Log registers when DPC
is triggered.
Link: https://lore.kernel.org/r/20240305113057.56468-1-pmenzel@molgen.mpg.de
Reported-by: Niels van Aert <nvaert1986@hotmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218560
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: <stable@vger.kernel.org>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Niels van Aert <nvaert1986@hotmail.com>
A race condition between the .runtime_idle() callback and the .remove()
callback in the rtsx_pcr PCI driver leads to a kernel crash due to an
unhandled page fault [1].
The problem is that rtsx_pci_runtime_idle() is not expected to be running
after pm_runtime_get_sync() has been called, but the latter doesn't really
guarantee that. It only guarantees that the suspend and resume callbacks
will not be running when it returns.
However, if a .runtime_idle() callback is already running when
pm_runtime_get_sync() is called, the latter will notice that the runtime PM
status of the device is RPM_ACTIVE and it will return right away without
waiting for the former to complete. In fact, it cannot wait for
.runtime_idle() to complete because it may be called from that callback (it
arguably does not make much sense to do that, but it is not strictly
prohibited).
Thus in general, whoever is providing a .runtime_idle() callback needs
to protect it from running in parallel with whatever code runs after
pm_runtime_get_sync(). [Note that .runtime_idle() will not start after
pm_runtime_get_sync() has returned, but it may continue running then if it
has started earlier.]
One way to address that race condition is to call pm_runtime_barrier()
after pm_runtime_get_sync() (not before it, because a nonzero value of the
runtime PM usage counter is necessary to prevent runtime PM callbacks from
being invoked) to wait for the .runtime_idle() callback to complete should
it be running at that point. A suitable place for doing that is in
pci_device_remove() which calls pm_runtime_get_sync() before removing the
driver, so it may as well call pm_runtime_barrier() subsequently, which
will prevent the race in question from occurring, not just in the rtsx_pcr
driver, but in any PCI drivers providing .runtime_idle() callbacks.
Link: https://lore.kernel.org/lkml/20240229062201.49500-1-kai.heng.feng@canonical.com/ # [1]
Link: https://lore.kernel.org/r/5761426.DvuYhMxLoT@kreacher
Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Ricky Wu <ricky_wu@realtek.com>
Acked-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: <stable@vger.kernel.org>
Apparently the LSI / Agere FW643 can't recover after a Secondary Bus Reset
and requires a power-off or suspend/resume and rescan.
VFIO resets a device before assigning it to a VM, and the FW643 doesn't
support any other reset methods, so this problem prevented assignment of
FW643 to VMs.
Prevent use of Secondary Bus Reset for this device.
With this change, the FW643 can be assigned to VMs with VFIO. Note that it
will not be reset, resulting in leaking state between VMs and host.
Link: https://lore.kernel.org/r/20240227131401.17913-1-edmund.raile@proton.me
Signed-off-by: Edmund Raile <edmund.raile@proton.me>
[bhelgaas: commit log, comment]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Commit c5eb119007 ("PCI / PM: Allow runtime PM without callback
functions") eliminated the need for PM callbacks in
pci_pm_runtime_suspend() and pci_pm_runtime_resume(), but
didn't do the same for pci_pm_runtime_idle().
Therefore, runtime suspend worked as long as the driver implemented at
least one PM callback. But if the driver doesn't implement any PM
callbacks at all (driver->pm is NULL), pci_pm_runtime_idle() returned
-ENOSYS, which prevented runtime suspend.
Modify pci_pm_runtime_idle() to allow PCI device power state transitions
without runtime PM callbacks and complete the original intention of commit
c5eb119007 ("PCI / PM: Allow runtime PM without callback functions").
Link: https://lore.kernel.org/r/20240227062648.16579-1-raag.jadav@intel.com
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
According to PCIe r6.0 sec 6.7.6 [1], async removal with DPC may result in
surprise down error. This error is expected and is just a side-effect of
async remove.
Ignore surprise down error generated as a side-effect of async remove.
Typically, this error is benign as the pciehp handler invoked by PDC
or/and DLLSC alongside DPC, de-enumerates and brings down the device
appropriately, but the error messages might confuse users. Get rid of
these irritating log messages with a 1s delay while pciehp waits for
DPC recovery.
The implementation is as follows: On an async remove a DPC is triggered
along with a Presence Detect State change and/or DLL State Change.
Determine it's an async remove by checking for DPC Trigger Status in DPC
Status Register and Surprise Down Error Status in AER Uncorrected Error
Status to be non-zero. If true, treat the DPC event as a side-effect of
async remove, clear the error status registers and continue with hot-plug
tear down routines. If not, follow the existing routine to handle AER and
DPC errors.
Masking Surprise Down Errors was explored as an alternative approach, but
discarded due to the odd behavior that masking only avoids the interrupt,
but still records an error per PCIe r6.0, sec 6.2.3.2.2. That stale error
would be reported the next time some error other than Surprise Down is
handled.
Dmesg before:
pcieport 0000:00:01.4: DPC: containment event, status:0x1f01 source:0x0000
pcieport 0000:00:01.4: DPC: unmasked uncorrectable error detected
pcieport 0000:00:01.4: PCIe Bus Error: severity=Uncorrected (Fatal), type=Transaction Layer, (Receiver ID)
pcieport 0000:00:01.4: device [1022:14ab] error status/mask=00000020/04004000
pcieport 0000:00:01.4: [ 5] SDES (First)
nvme nvme2: frozen state error detected, reset controller
pcieport 0000:00:01.4: DPC: Data Link Layer Link Active not set in 1000 msec
pcieport 0000:00:01.4: AER: subordinate device reset failed
pcieport 0000:00:01.4: AER: device recovery failed
pcieport 0000:00:01.4: pciehp: Slot(16): Link Down
nvme2n1: detected capacity change from 1953525168 to 0
pci 0000:04:00.0: Removing from iommu group 49
Dmesg after:
pcieport 0000:00:01.4: pciehp: Slot(16): Link Down
nvme1n1: detected capacity change from 1953525168 to 0
pci 0000:04:00.0: Removing from iommu group 37
[1] PCI Express Base Specification Revision 6.0, Dec 16 2021.
https://members.pcisig.com/wg/PCI-SIG/document/16609
Link: https://lore.kernel.org/r/20240207181854.121335-1-Smita.KoralahalliChannabasappa@amd.com
Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Per PCIe r6.1, sec 2.2.6.2 and 7.5.3.4, a Requester may not use 8-bit Tags
unless its Extended Tag Field Enable is set, but all Receivers/Completers
must handle 8-bit Tags correctly regardless of their Extended Tag Field
Enable.
Some devices do not handle 8-bit Tags as Completers, so add a quirk for
them. If we find such a device, we disable Extended Tags for the entire
hierarchy to make peer-to-peer DMA possible.
The 3ware 9650SE seems to have issues with handling 8-bit tags. Mark it as
broken.
This fixes PCI Parity Errors like :
3w-9xxx: scsi0: ERROR: (0x06:0x000C): PCI Parity Error: clearing.
3w-9xxx: scsi0: ERROR: (0x06:0x000D): PCI Abort: clearing.
3w-9xxx: scsi0: ERROR: (0x06:0x000E): Controller Queue Error: clearing.
3w-9xxx: scsi0: ERROR: (0x06:0x0010): Microcontroller Error: clearing.
Link: https://lore.kernel.org/r/20240219132811.8351-1-joerg@wedekind.de
Fixes: 60db3a4d8c ("PCI: Enable PCIe Extended Tags if supported")
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=202425
Signed-off-by: Jörg Wedekind <joerg@wedekind.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The definition of a reserved BAR is that EPF drivers should not touch
them.
The definition of only_64bit is that the EPF driver must configure this
BAR as 64-bit. (An EPF driver is not allowed to choose if this BAR should
be configured as 32-bit or 64-bit.)
Thus, it does not make sense to put only_64bit of a BAR that EPF drivers
are not allow to touch.
Drop the only_64bit property from hardware descriptions that are of type
reserved BAR.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Kishon Vijay Abraham I <kishon@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20240216134524.1142149-3-cassel@kernel.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
The hardware description for BARs is scattered in many different variables
in pci_epc_features. Some of these things are mutually exclusive, so it
can create confusion over which variable that has precedence over another.
Improve the situation by creating a struct pci_epc_bar_desc, and a new
enum pci_epc_bar_type, and convert the endpoint controller drivers to use
this more well defined format.
Additionally, some endpoint controller drivers mark the BAR succeeding a
"64-bit only BAR" as reserved, while some do not. By definition, a 64-bit
BAR uses the succeeding BAR for the upper 32-bits, so an EPF driver cannot
use a BAR succeeding a 64-bit BAR. Ensure that all endpoint controller
drivers are uniform, and actually describe a reserved BAR as reserved.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Kishon Vijay Abraham I <kishon@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20240216134524.1142149-2-cassel@kernel.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Add support for Qualcomm Snapdragon SA8775P SoC to the EPF driver.
SA8775P is currently reusing the PID 0x0306 (the default one hardcoded
in the config space header) as the unique PID is not yet allocated.
But the host side stack works fine with the default PID. It will get
updated once the PID is finalized. Also, it has no fixed PCI class as of
now, so it is being advertised as "PCI_CLASS_OTHERS".
Signed-off-by: Mrinmay Sarkar <quic_msarkar@quicinc.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/1701432377-16899-5-git-send-email-quic_msarkar@quicinc.com
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Without the prefix, the function name would appear as
"/sys/kernel/config/functions/{sdx55/sm8450}". This will be a problem if
multiple functions are supported for this endpoint device.
So let's add the "pci_epf_mhi_" prefix to identify _this_ function
uniquely. Even though it is an ABI breakage, this driver is not used
anywhere outside Qcom and myself to my knowledge. So it safe to change
the function name.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Mrinmay Sarkar <quic_msarkar@quicinc.com>
Link: https://lore.kernel.org/r/1701432377-16899-4-git-send-email-quic_msarkar@quicinc.com
If dma_set_mask_and_coherent() in pci_vntb_probe() fails, return the actual
error code instead of -EINVAL.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20231201033057.1399131-2-yangyingliang@huaweicloud.com
[mani: reworded commit message and subject]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
If device_register() fails in ntb_register_device(), the device name
allocated by dev_set_name() should be freed. As per the comment in
device_register(), callers should use put_device() to give up the
reference in the error path. So fix this by calling put_device() in the
error path so that the name can be freed in kobject_cleanup().
As a result of this, put_device() in the error path of
ntb_register_device() is removed and the actual error is returned.
Fixes: a1bd3baeb2 ("NTB: Add NTB hardware abstraction layer")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/20231201033057.1399131-1-yangyingliang@huaweicloud.com
[mani: reworded commit message]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
The file pci.c is very large and contains a number of devres functions.
These functions should now reside in devres.c.
Move as much devres-specific code from pci.c to devres.c as possible.
There are a few callers left in pci.c that do devres operations. These
should be ported in the future. Add corresponding TODOs.
The reason they are not moved right now in this commit is that PCI's devres
currently implements a sort of "hybrid-mode": pci_request_region(), for
instance, does not have a corresponding pcim_ equivalent, yet. Instead, the
function can be made managed by previously calling pcim_enable_device()
(instead of pci_enable_device()). This makes it unreasonable to move
pci_request_region() to devres.c. Moving the functions would require
changes to PCI's API and is, therefore, left for future work.
In summary, this commit serves as a preparation step for a following
patch series that will cleanly separate the PCI's managed and unmanaged
API.
Link: https://lore.kernel.org/r/20240131090023.12331-5-pstanner@redhat.com
Suggested-by: Danilo Krummrich <dakr@redhat.com>
Signed-off-by: Philipp Stanner <pstanner@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The pcim_*() functions in lib/devres.c are guarded by an #ifdef CONFIG_PCI
and, thus, don't belong to this file. They are only ever used for PCI and
are not generic infrastructure.
Move all pcim_*() functions in lib/devres.c to drivers/pci/devres.c.
Adjust the Makefile.
Add drivers/pci/devres.c to Documentation.
Link: https://lore.kernel.org/r/20240131090023.12331-4-pstanner@redhat.com
Suggested-by: Danilo Krummrich <dakr@redhat.com>
Signed-off-by: Philipp Stanner <pstanner@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The entirety of pci_iomap.c is guarded by an #ifdef CONFIG_PCI. It,
consequently, does not belong to lib/ because it is not generic
infrastructure.
Move pci_iomap.c to drivers/pci/ and implement the necessary changes to
Makefiles and Kconfigs.
Update MAINTAINERS file.
Update Documentation.
Link: https://lore.kernel.org/r/20240131090023.12331-3-pstanner@redhat.com
[bhelgaas: squash in https://lore.kernel.org/r/20240212150934.24559-1-pstanner@redhat.com]
Suggested-by: Danilo Krummrich <dakr@redhat.com>
Signed-off-by: Philipp Stanner <pstanner@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Now that the checks are performed by the pci_epf_alloc_space() API, let's
remove the superfluous checks in this driver.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20240207213922.1796533-5-cassel@kernel.org
[mani: reworded the commit message]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Now that the checks are performed by the pci_epf_alloc_space() API, let's
remove the superfluous checks in this driver.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/20240207213922.1796533-4-cassel@kernel.org
[mani: reworded commit message]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
pci_epf_alloc_space() already performs checks on the requested BAR size,
and will allocate and set epf_bar->size to a size higher than the
requested BAR size if some constraint deems it necessary.
However, there are additional checks done in the function drivers like
pci-epf-test.c, other than the existing checks in this API.
And similar checks are proposed to other endpoint function drivers, see:
https://lore.kernel.org/linux-pci/20240108151015.2030469-1-Frank.Li@nxp.com
Having these checks scattered over different locations in multiple EPF
drivers is not maintainable and makes the code hard to follow.
Since pci_epf_alloc_space() already performs roundups and some checks,
let's move the additional checks from pci-epf-test.c to
pci_epf_alloc_space().
This makes the API more robust and also offloads the checks from the
function drivers.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/20240207213922.1796533-3-cassel@kernel.org
[mani: reworded commit message and fixed uninitialized 'dev' pointer issue]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Refactor pci_epf_alloc_space() API to accept "epc_features" as a parameter.
This is a preparatory work to make the API more robust.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Link: https://lore.kernel.org/r/20240207213922.1796533-2-cassel@kernel.org
[mani: reworded commit message]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
