| Age | Commit message (Collapse) | Author |
|---|
|
https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git
# Conflicts:
# Documentation/devicetree/bindings/usb/am33xx-usb.txt
# Documentation/devicetree/bindings/usb/da8xx-usb.txt
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git
|
|
- TBD
* pci/controller/xilinx-cpm:
PCI: xilinx-cpm: Add support for PCIe RP PERST# signal
dt-bindings: PCI: xilinx-versal-cpm: Add PERST# and reset support
|
|
- Use devm for clocks so they're automatically disabled, unprepared, and
released if errors happen during probe (Yuho Choi)
* pci/controller/xgene:
PCI: xgene: Use managed clock for PCIe controller
|
|
- Flush initiator posted writes before calling IRQ handler to work around a
Meteor Lake erratum, where a DMA completion MSI can arrive before the
completion queue in memory has been updated, resulting in an nvme 30
second stall before a QID timeout and possibly other similar problems
(Rickey Bartlett)
* pci/controller/vmd:
PCI: vmd: Flush initiator posted writes before demuxing interrupts on Meteor Lake
|
|
- Disable refclk on probe failure (Lad Prabhakar)
- Propagate platform_get_irq_byname() errors so probe deferral works
correctly (Lad Prabhakar)
- Tear down INTx handlers if subsequent initialization fails (Lad
Prabhakar)
- Add RZ/G3L (R9A08G046) DT and driver support (Biju Das)
* pci/controller/rzg3s-host:
PCI: rzg3s-host: Add support for RZ/G3L SoC
dt-bindings: PCI: renesas,r9a08g045s33-pcie: Document RZ/G3L SoC
PCI: rzg3s: Fix IRQ domain initialization error handling
PCI: rzg3s: Propagate platform_get_irq_byname() errors
PCI: rzg3s: Disable refclk on probe failure
|
|
- Fix a 64-bit type truncation in mtk_pcie_set_trans_table() to avoid
issues with windows above or larger than 4GB (Sreeraj S Kurup)
* pci/controller/mediatek-gen3:
PCI: mediatek-gen3: Fix 64-bit type truncation in mtk_pcie_set_trans_table()
|
|
- Find INTx DT property by 'interrupt-controller' name instead of assuming
it's the first child node (Zhengping Zhang)
* pci/controller/mediatek:
PCI: mediatek: Find INTx controller by property
|
|
- Limit Max_Read_Request_Size to 256 to avoid hardware erratum (Marek
Vasut)
- Add a .post_deinit() callback to handle dw_pcie_ep_init() failures (Marek
Vasut)
* pci/controller/dwc-rcar-gen4:
PCI: rcar-gen4: Use .post_deinit() to handle dw_pcie_ep_init() failures
PCI: dwc: Add dw_pcie_ep_ops->post_deinit() callback
PCI: rcar-gen4: Limit Max_Read_Request_Size to 256 Bytes
|
|
- Only collect reset GPIOs from PCI bridge DT nodes to avoid stealing
resets used by downstream devices like USB controllers (Christopher
Obbard)
- Block accesses to downstream devices on link down to reduce a storm of
Completion Timeout AER interrupts (Qiang Yu)
- Skip system suspend/resume for firmware-managed PCIe, where firmware
manages clocks, regulators, resets, etc (Mrinmay Sarkar)
* pci/controller/dwc-qcom:
PCI: qcom: Skip system suspend/resume for firmware-managed PCIe
PCI: qcom: Block accesses to downstream devices on link down
PCI: qcom: Only check bridge nodes for PERST# GPIOs
|
|
- Fix pwrctrl device leak when .probe() PM runtime setup fail (hanzhijian)
- Enable clock after core reset is asserted to fix enumeration regression
on i.MX6Q Apalis platforms with ASM1061/ASM1062 SATA controllers (Richard
Zhu)
- Improve i.MX95 Gen3 link stability by changing MPLLB_BANDWIDTH from
default 120 to 140 (Richard Zhu)
* pci/controller/dwc-imx6:
PCI: imx6: Update MPLLB bandwidth to improve i.MX95 Gen3 PCIe stability
PCI: imx6: Move clock enable after core reset assertion
PCI: imx6: Fix pwrctrl device leak on PM runtime setup failure
|
|
- Fix enum type mismatch warning in LTSSM debugfs (Hans Zhang)
* pci/controller/cadence:
PCI: cadence: Fix enum type mismatch warning in LTSSM debugfs
|
|
- Fix clk and PHY leaks in aspeed_pcie_port_init() error paths (Liu
Zhenlong)
* pci/controller/aspeed:
PCI: aspeed: Fix clk and PHY leak in aspeed_pcie_port_init() error paths
|
|
- Return error (not success) from cdns_plat_pcie_probe() if
pm_runtime_get_sync() or cdns_pcie_ep_setup() failed (Vladimir Oltean)
- Add missing headers transitively included by <linux/phy/phy.h> so these
can be removed from linux/phy/phy.h itself (Vladimir Oltean)
- Remove device links to PHY, which are redundant because the PHY core
itself adds them (Vladimir Oltean)
* pci/controller/misc:
PCI: Remove device links to PHY
PCI: Add missing headers transitively included by <linux/phy/phy.h>
PCI: cadence: Preserve all error codes in cdns_plat_pcie_probe()
|
|
- Pass the correct physical and virtual endpoint function numbers when
setting translation of inbound memory windows (Koichiro Den)
- Make embedded doorbell IRQ non-shared, since currently only the first EPF
can allocate doorbells (Koichiro Den)
- MSI doorbells currently target the first EPF attached to an EPC; let
other EPFs try the embedded doorbell instead of failing when they can't
use the MSI doorbell (Koichiro Den)
- Serialize scan of vNTB virtual PCI bus with other PCI topology changes
(Koichiro Den)
- Manage vNTB lifetimes to avoid leaking virtual devices and buses and
allow removal (Koichiro Den)
* pci/endpoint:
PCI: endpoint: pci-epf-vntb: Manage virtual NTB and PCI bus lifetime
PCI: endpoint: pci-epf-vntb: Serialize virtual PCI bus scan
PCI: endpoint: pci-ep-msi: Let non-first EPFs use embedded doorbells
PCI: endpoint: pci-ep-msi: Make embedded doorbell IRQ exclusive
PCI: endpoint: pci-epf-vntb: Pass PF/VF number when BAR programming
|
|
- Add ACS quirk for Pericom PI7C9X2G304 switches (Hans de Goede)
* pci/virtualization:
PCI: Add ACS quirk for Pericom PI7C9X2G304 switches [12d8:b304]
|
|
- TBD
* pci/reset:
PCI: Add device-specific reset for Qualcomm devices
|
|
- Use regmap APIs for tc9563 I2C accesses instead of open-coding I2C
transfers (Lorenzo Bianconi)
- Use devm-managed tc9563 I2C dummy device allocation (Lorenzo Bianconi)
- Allow tc9563 RESX reset assertion to sleep (Abel Vesa)
* pci/pwrctrl:
PCI/pwrctrl: tc9563: Allow RESX reset assertion to sleep
PCI/pwrctrl: tc9563: Use devm-managed I2C dummy device allocation
PCI/pwrctrl: tc9563: Rely on regmap APIs
|
|
- Add Zhaoxin KX-6000, KH-40000, KX-6000G, KX-7000, and KH-50000 host
bridges to allowlist (LeoLiu-oc)
- Update DMABUF lifecycle docs renaming move_notify() (Leon Romanovsky)
- Fix handling of errors in pci_p2pdma_add_resource() to avoid (a)
unmapping a BAR if registering another fails and (b) use after free of
p2p_pgmap (Leon Romanovsky)
- Wait for RCU readers before freeing state to avoid use-after-free of
pdev->p2pdma (Leon Romanovsky)
- Restrict pci_p2pmem_find_many() to providers backed by a pool (Leon
Romanovsky)
- Safely terminate ACS redirect lists to avoid out-of-bounds access to the
buffer (Leon Romanovsky)
- Silence 'Host bridge not in P2PDMA whitelist' warnings unless caller,
e.g., pci_p2pmem_find_many(), requests 'verbose' (Leon Romanovsky)
* pci/p2pdma:
PCI/P2PDMA: Gate the host bridge whitelist warning on verbose
PCI/P2PDMA: Safely terminate ACS redirect lists
PCI/P2PDMA: Restrict the p2pmem search to pool-backed providers
PCI/P2PDMA: Wait for RCU readers before freeing state
PCI/P2PDMA: Do not tear down the allocate attribute on registration failure
PCI/P2PDMA: Update DMABUF lifecycle docs after move_notify() rename
PCI/P2PDMA: Add Zhaoxin host bridges to allowlist
|
|
HDMA supports configurable DMA channel register space
separation which ranges from 256B to 32KB. Current implementation
supports 256B as default for DMA channel register space.
CPM6 supports the selection of channel register space via VSEC.
The default value for channel register space for CPM6 is 512B.
Updated the functions and methods to calculate the DMA channel
registers base address as per the selected channel separation
available as part of 'ch_space_sz'. Removed the unused function
__dw_regs() and structs, namely dw_hdma_v0_ch and dw_hdma_v0_regs.
Signed-off-by: Devendra K Verma <devverma@amd.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260907101213.1917064-3-devverma@amd.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
According to the existing quirk the Pericom E5 errata for ACS P2P applies
to PI7C9X2G404, PI7C9X2G304 and PI7C9X2G303 models.
The Arduino Ventuno Q board has a PI7C9X2G304 switch (verified from chip
markings) with a product-id of 0xb304. Add 12d8:b304 to the existing list
of quirks for this erratum.
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20260820082041.13470-1-johannes.goede@oss.qualcomm.com
|
|
Some Qualcomm PCIe devices (WCN6855/WCN7850 WLAN cards, SDX62/SDX65 modems)
lack working reset methods for VFIO passthrough scenarios. These devices
have no FLR capability, advertise NoSoftRst+ (blocking PM reset), and have
broken bus reset.
The problem manifests in VFIO passthrough scenarios:
- WCN6855 (17cb:1103) and WCN7850 (17cb:1107) WLAN devices: Normal VM
operation works fine, including clean shutdown/reboot. However, when
the VM terminates uncleanly (crash, force-off), VFIO attempts to reset
the device before it can be assigned to another VM. Without a working
reset method, the device remains in an undefined state, preventing
reuse.
- SDX62/SDX65 (17cb:0308) 5G modems: Never successfully initialize even
on first VM assignment without proper reset capability.
Add device-specific reset methods using BAR-space hardware reset registers
that exist in these devices:
- WCN6855/WCN7850 WLAN devices use SoC global reset via BAR0 (sequence
from ath11k/ath12k driver: ath11k_pci_soc_global_reset(),
ath11k_pci_sw_reset(), ath11k_mhi_set_mhictrl_reset()):
- Write/clear reset bit at offset 0x3008
- Wait for PCIe link recovery (up to 5 seconds)
- Clear MHI controller SYSERR status at offset 0x38
- SDX62/SDX65 modem devices use MHI SoC reset via BAR0 (sequence from MHI
driver: mhi_soc_reset(), mhi_pci_reset_prepare()):
- Write reset request to offset 0xb0
- Wait 2 seconds for reset completion
These are true hardware reset mechanisms (not power management or firmware
error recovery), providing proper device reset for VFIO scenarios.
Testing was performed on desktop platforms with M.2 WLAN and modem cards
using M.2-to-PCIe adapters, including extensive force-reset cycling to
verify stability.
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20260721081301.205374-1-jtornosm@redhat.com
|
|
pcie_aspm_enabled() returns 'pcie_link_state::aspm_enabled' parameter which
contains the enabled states. But the API currently returns the 'bool' type
which is used by the callers to decide if ASPM is enabled or not.
To allow the future callers to also make use of the enabled ASPM states,
return the actual type of 'pcie_link_state::aspm_enabled' parameter, 'u32'.
Existing callers can still treat the return value as a 'bool' as the C11
standard guarantees the behavior (this API relied on the same behavior
before as well).
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260708-pci-aspm-fix-v3-5-6bd72451746e@kernel.org
|
|
Add kernel-doc for pci_disable_link_state_locked() API and fix the
kernel-doc for pci_disable_link_state() API.
Also convert the kernel-doc of pci_enable_link_state() and
pci_enable_link_state_locked() APIs to the standard format and mention that
pci_force_enable_link_state() should be used to re-enable the states
disabled by pci_disable_link_state().
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260708-pci-aspm-fix-v3-4-6bd72451746e@kernel.org
|
|
states
Per PCIe spec r6.0, sec 5.5.4:
If setting either or both of the enable bits for PCI-PM L1 PM Substates,
both ports must be configured as described in this section while in D0.
Currently, the callers of pci_enable_link_state_locked() (vmd, pcie-qcom)
transition the device to D0 themselves before enabling the link state. But
this is easy to get wrong and has to be duplicated by every caller.
Move the D0 transition into the shared __pci_enable_link_state() helper so
that all three APIs pci_enable_link_state(), pci_enable_link_state_locked()
and pci_force_enable_link_state() perform it, and only when the PCI-PM L1
PM Substates are getting enabled.
Now that the helper handles the transition, drop the redundant D0
transition from the vmd and pcie-qcom callers.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260708-pci-aspm-fix-v3-3-6bd72451746e@kernel.org
|
|
pci_enable_link_state() and pci_enable_link_state_locked() APIs only enable
the ASPM states that were not previously disabled via
pci_disable_link_state*() API or blacklisted during init (e.g. the pre-1.1
device blacklist, which is only meant to be overridden with
'pcie_aspm=force'). This is an intentional behavior as these APIs must not
silently re-enable states that were deliberately disabled, since doing so
could enable ASPM on a link where it is known to be unsafe.
However, some drivers (e.g. the atheros WLAN drivers) save the currently
enabled ASPM states, disable all ASPM states before firmware download, and
then try to restore exactly the states that were enabled before. Restoring
those states requires re-enabling states that were just disabled via
pci_disable_link_state() API. But, this cannot be achieved using the
existing APIs.
Hence, add pci_force_enable_link_state() API for such callers. Unlike
pci_enable_link_state(), it re-enables the requested states even if they
were previously disabled via pci_disable_link_state() or disabled during
init. The caller is therefore responsible for only enabling states the
device actually supports, typically the ones previously reported by
pcie_aspm_enabled().
This API is implemented by adding a 'force' parameter to the shared
__pci_enable_link_state() helper. When 'force' is true, the requested
states are cleared from 'link->aspm_disable' before enabling.
Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260708-pci-aspm-fix-v3-2-6bd72451746e@kernel.org
|
|
PCI core/ASPM service driver allows controlling ASPM state through
pci_disable_link_state() API. It was decided earlier (see the Link below),
to not allow ASPM changes when OS does not have control over it but only
log a warning about the problem 'commit 2add0ec14c25 ("PCI/ASPM: Warn when
driver asks to disable ASPM, but we can't do it")'.
A number of drivers have added workarounds to force ASPM off with own
writes into the Link Control Register (some even with comments explaining
why PCI core does not disable it under some circumstances). According to
the comments, some drivers require ASPM to be off for reliable operation.
Having custom ASPM handling in drivers is problematic because the state
kept in the ASPM service driver is not updated by the changes made outside
the link state management API.
As the first step to address this issue, make pci_disable_link_state() to
unconditionally disable ASPM so the motivation for drivers to come up with
custom ASPM handling code is eliminated.
To fully take advantage of the ASPM handling core provides, the drivers
that need to quirk ASPM have to be altered depend on PCIEASPM and the
custom ASPM code is removed. This is to be done separately. As PCIEASPM is
already behind EXPERT, it should be no problem to limit disabling it for
configurations that do not require touching ASPM.
Make pci_disable_link_state() function comment to comply kerneldoc
formatting while changing the description.
Link: https://lore.kernel.org/all/CANUX_P3F5YhbZX3WGU-j1AGpbXb_T9Bis2ErhvKkFMtDvzatVQ@mail.gmail.com/
Link: https://lore.kernel.org/all/20230511131441.45704-1-ilpo.jarvinen@linux.intel.com/
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
[mani: commit message fixup]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260708-pci-aspm-fix-v3-1-6bd72451746e@kernel.org
|
|
The virtual PCI driver registers an ntb_dev but has no remove callback.
Unbinding the endpoint function can therefore free BARs while the NTB
device and its client still use them. It also leaves the virtual PCI
devices and root bus allocated.
Allocate an ntb_dev for each virtual PCI probe and unregister it from the
matching remove callback. Start command processing only after registration.
Publish the device for doorbell IRQs at the same point. During remove, stop
the command work and drain IRQ handlers before unregistering the device.
Retain the root bus returned by pci_scan_bus() so it can be removed on
unbind. Unregister the virtual PCI driver before releasing endpoint
resources. Stop and remove the root bus under the PCI rescan/remove lock,
then release its host bridge.
Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP")
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Cc: stable@vger.kernel.org # 6.0+
Link: https://patch.msgid.link/20260901063238.631166-3-den@valinux.co.jp
|
|
calc_map_type_and_dist() prints every other diagnostic under its verbose
argument, but reaches the "Host bridge not in P2PDMA whitelist" warning
through host_bridge_whitelist(), which it hands acs_redirects instead. A
caller that asked for a silent answer still gets the warning whenever any
port on the path has an ACS redirect bit set, the CPU is not whitelisted by
cpu_supports_p2pdma(), and the host bridge is not in
pci_p2pdma_whitelist[].
pci_p2pmem_find_many() is such a caller. It sweeps every device with
published p2pmem and asks for the distance to each client with
verbose=false, and pci_p2pdma_distance_many() recomputes rather than
consulting the map_types cache, so the warning repeats on every sweep.
The argument was never meant to say "ACS redirects were found". When commit
cf201bfe8cdc ("PCI/P2PDMA: Warn if host bridge not in whitelist") added it,
acs_redirects was a bool pointer that the quiet entry point passed as NULL:
if (verbose)
map = calc_map_type_and_dist_warn(provider, pci_client,
&distance);
else
map = calc_map_type_and_dist(provider, pci_client,
&distance, NULL, NULL);
so the argument was true on exactly the path that commit describes.
Folding the two entry points into one verbose flag turned the pointer into
a value and left the call site alone, silently narrowing the warning to
paths that carry an ACS redirect.
Pass verbose. This also restores the warning for a verbose caller that
takes the host bridge route with no ACS redirect on the path, which until
now was told it could not use peer-to-peer DMA without being told which
vendor and device would have to be added to the whitelist.
Fixes: d1b8dc09dd71 ("PCI/P2PDMA: Simplify distance calculation")
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Tushar Dave <tdave@nvidia.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Link: https://patch.msgid.link/20260830-batch-p2p-fixes-v1-5-5044e8dfbe2e@nvidia.com
|
|
seq_buf marks an overflow by setting len to size + 1. The ACS diagnostic
path unconditionally writes a terminator to buffer[len - 1], so a path with
enough ACS ports to fill the 128-byte buffer writes one byte beyond the
buffer when verbose diagnostics are requested.
Use seq_buf_str() to terminate truncated output safely and remove the final
semicolon only when the buffer did not overflow.
Fixes: 52916982af48 ("PCI/P2PDMA: Support peer-to-peer memory")
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Tushar Dave <tdave@nvidia.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://patch.msgid.link/20260830-batch-p2p-fixes-v1-4-5044e8dfbe2e@nvidia.com
|
|
pci_p2pmem_find_many() exists to pick a provider that the caller will then
allocate from with pci_alloc_p2pmem(), which goes straight to the gen_pool:
ret = (void *)gen_pool_alloc_owner(p2pdma->pool, size, (void **) &ref);
pci_has_p2pmem() does not ask for that pool, only for the published flag.
The two used to be equivalent, because a provider could only exist by way
of pci_p2pdma_add_resource(), which always creates the pool.
pcim_p2pdma_init() broke that. It registers a provider for the DMABUF path
and never creates a pool, so pdev->p2pdma is set while p2pdma->pool stays
NULL. Nothing publishes such a provider today, so the search cannot return
one yet, but the flag alone no longer says what the caller needs.
Ask for the pool as well, so the search covers the providers its result is
used for. A later patch documents the pdev->p2pdma lifetime and RCU rules.
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Tushar Dave <tdave@nvidia.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://patch.msgid.link/20260830-batch-p2p-fixes-v1-3-5044e8dfbe2e@nvidia.com
|
|
pci_p2pmem_find_many() scans all PCI devices without locking or protection
against driver unbind, including devices with poolless P2PDMA state.
pci_has_p2pmem() may observe pdev->p2pdma just before driver unbind clears
it, while pci_p2pdma_release() skips the grace period when no pool is
present. This allows devres to free the object while it is still in use.
Clear the pointer with RCU_INIT_POINTER() and always wait for pre-existing
RCU readers before returning. The same grace period continues to protect
gen_pool users for pool-backed providers.
Fixes: 372d6d1b8ae3 ("PCI/P2PDMA: Refactor to separate core P2P functionality from memory allocation")
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Tushar Dave <tdave@nvidia.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Cc: Alex Williamson <alex@shazbot.org>
Cc: Matt Evans <matt@ozlabs.org>
Link: https://patch.msgid.link/20260830-batch-p2p-fixes-v1-2-5044e8dfbe2e@nvidia.com
|
|
pci_p2pdma_add_resource() installs pci_p2pdma_unmap_mappings() as a devres
action with the devres allocated p2p_pgmap as its data, and only then adds
the range to the pool:
error = devm_add_action_or_reset(&pdev->dev, pci_p2pdma_unmap_mappings,
p2p_pgmap);
if (error)
goto pages_free;
p2pdma = rcu_dereference_protected(pdev->p2pdma, 1);
error = gen_pool_add_owner(p2pdma->pool, ...);
if (error)
goto pages_free;
The action removes the allocate attribute for the whole device, which tears
down existing userspace mappings of every BAR already registered on it.
Both failures here get that wrong, in opposite ways.
devm_add_action_or_reset() runs the action when it cannot allocate its
devres node, so an -ENOMEM while registering a second BAR unmaps the first
one. Use devm_add_action() and let the error path unwind only what this
call created.
gen_pool_add_owner() allocates a chunk and can also fail with -ENOMEM.
There the action is registered, and the error path frees p2p_pgmap with
devm_kfree() while leaving the action pointing at it. On unbind devres
runs the action and pci_p2pdma_unmap_mappings() dereferences
p2p_pgmap->mem->owner->kobj, which is freed memory. Give that failure its
own label and drop the action with devm_remove_action(), which removes it
without running it.
Fixes: 7e9c7ef83d78 ("PCI/P2PDMA: Allow userspace VMA allocations through sysfs")
Fixes: f58ef9d1d135 ("PCI/P2PDMA: Separate the mmap() support from the core logic")
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Tushar Dave <tdave@nvidia.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://patch.msgid.link/20260830-batch-p2p-fixes-v1-1-5044e8dfbe2e@nvidia.com
|
|
Poor bandwidth margins are observed during i.MX95 Gen3 PCIe tests with the
default MPLLB_BANDWIDTH value (120). The margins worsened across voltage
and temperature (VT) variations and different test matrices, potentially
causing link stability issues.
Testing with MPLLB_BANDWIDTH value of 140 (0x8c) shows significant
improvement in bandwidth margins across all VT conditions and test
scenarios.
Implement PHY register write helper function and configure:
- MPLLB_BW_OVRD_IN = 140 (0x8c) for improved bandwidth margin
- MPLLB_BW_OVRD_EN to enable the override
This ensures robust PCIe Gen3 performance across all operating conditions.
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
[mani: added regmap_read() to flush IMX95_PCIE_PHY_CR_PARA_SEL update]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260803034319.992323-1-hongxing.zhu@oss.nxp.com
|
|
Add SoC-specific data for the RZ/G3L (R9A08G046) PCIe controller and
register its "renesas,r9a08g046-pcie" compatible string. RZ/G3L reuses
the RZ/G3E config init/deinit callbacks and power resets, with its own
L1-allow syscon offset and mask.
Also increase the timeout in rzg3s_pcie_set_max_link_speed() to fix
the "Failed to set max link speed" message seen on RZ/G3L.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260903133320.144245-3-biju.das.jz@bp.renesas.com
|
|
The virtual PCI bus is scanned without holding the PCI rescan/remove
lock. This can race with other PCI topology changes.
Hold the lock across the bus scan and device addition.
Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP")
Suggested-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/3tgrcel5fl55ulf3zjya4fkz4t2ms7iwwjif5rnzn2rafsydd6@i4e5etm7uqvz/
Link: https://patch.msgid.link/20260901063238.631166-2-den@valinux.co.jp
|
|
rzg3s_pcie_init_irqdomain() installs chained handlers for the INTx
parent interrupts before creating the INTx irqdomain and initializing
MSI support.
If any subsequent step fails, such as obtaining an INTx IRQ,
creating the irqdomain, or initializing MSI, the error path returns
without removing any chained handlers that were already installed.
This leaves stale handler and data pointers attached to the parent
interrupts.
Add a helper to tear down the INTx IRQ setup, including removing the IRQ
domain and clearing the chained handlers. Use it to unwind partially
completed initialization and from the normal IRQ domain teardown path.
Fixes: 7ef502fb35b28 ("PCI: Add Renesas RZ/G3S host controller driver")
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260811200013.185956-4-prabhakar.mahadev-lad.rj@bp.renesas.com
|
|
platform_get_irq_byname() may return specific error codes such as
-EPROBE_DEFER, but rzg3s_pcie_init_irqdomain() replaces all failures
with -EINVAL.
This breaks probe deferral by preventing the driver core from retrying
probe once the interrupt provider becomes available.
Propagate the original error code instead.
Fixes: 7ef502fb35b28 ("PCI: Add Renesas RZ/G3S host controller driver")
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260811200013.185956-3-prabhakar.mahadev-lad.rj@bp.renesas.com
|
|
rzg3s_pcie_host_init_port() enables the PCIe reference clock using
clk_prepare_enable(), but if rzg3s_pcie_probe() subsequently fails, for
example because pci_host_probe() returns an error, the probe error path
only releases the clock handle with clk_put().
Balance clk_prepare_enable() by calling clk_disable_unprepare() in the
probe cleanup path before releasing the clock, ensuring the reference
clock is properly disabled on probe failure.
Fixes: 7ef502fb35b28 ("PCI: Add Renesas RZ/G3S host controller driver")
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260811200013.185956-2-prabhakar.mahadev-lad.rj@bp.renesas.com
|
|
This is practically a full revert of commit
7a4db656a635 ("PCI: dra7xx: Create functional dependency between PCIe and PHY")
and a partial revert of the device link pieces from commits
dfb80534692d ("PCI: cadence: Add generic PHY support to host and EP drivers")
49229238ab47 ("PCI: keystone: Cleanup PHY handling")
The trouble with these commits is that they dereference fields inside
struct phy from a consumer driver, which will become no longer possible.
Since commit 987351e1ea77 ("phy: core: Add consumer device link
support") from 2019, the PHY core also adds a device link to order PHY
provider and consumer suspend/resume operations. All reverted commits
are from 2017-2018, and what they do should actually be redundant now.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260810124315.433448-4-vladimir.oltean@nxp.com
|
|
The tegra as well as a few dwc PCI controller drivers uses PM runtime
operations without including the required <linux/pm_runtime.h> header.
Similarly, pcie-rockchip-host, pcie-starfive as well as a few dwc PCI
controllers use the regulator consumer API without including
<linux/regulator/consumer.h>.
pcie-spacemit-k1.c uses of_get_next_available_child() and of_node_put()
without including <linux/of.h>.
It seems these function prototypes were indirectly provided by
<linux/phy/phy.h>, mostly by mistake (none of the functions it exports
need it).
Before the PHY header can drop the unnecessary includes, make sure the
PCI controller drivers include what they use.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260810124315.433448-3-vladimir.oltean@nxp.com
|
|
The blamed commit functionally changed the error path of
cdns_pcie_host_probe(), now cdns_plat_pcie_probe().
When the old code path executed "goto err_get_sync", the PCIe controller
probe function propagated the pm_runtime_get_sync() error code. The new
code doesn't, and returns 0.
Similarly for the "goto err_init" previously triggered by
cdns_pcie_host_init() errors, and now triggered by
cdns_pcie_host_setup() and cdns_pcie_ep_setup() errors. These are not
propagated and will result in probing success, which is incorrect.
Fixes: bd22885aa188 ("PCI: cadence: Refactor driver to use as a core library")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260810124315.433448-2-vladimir.oltean@nxp.com
|
|
All existing DTS users already name the INTx child node
"interrupt-controller". Use of_get_child_by_name() to find it instead
of assuming it is the first child node.
Signed-off-by: Zhengping Zhang <aquapinn@qq.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/tencent_5E7D6E7FB25B4CD732F08547C11F5DA24808@qq.com
|
|
xgene_pcie_init_port() obtains and enables the controller clock manually.
When xgene_pcie_setup() or pci_host_probe() fails, probe returns without
disabling, unpreparing, or releasing the clock. A failed enable also leaves
the clk_get() reference unreleased.
Use devm_clk_get_enabled() so the clock is unwound automatically on probe
failure and device removal.
Fixes: 5f6b6ccdbe1c ("PCI: xgene: Add APM X-Gene PCIe driver")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260802221146.573233-1-dbgh9129@gmail.com
|
|
The variables cpu_addr, pci_addr, and remaining in
mtk_pcie_set_trans_table() are of type resource_size_t, which is 64-bit
on 64-bit architectures.
Using 32-bit helpers fls(), ffs(), and BIT() causes 64-bit integer
truncation when computing window sizes and address alignments above 4GB.
Fix this by switching to fls64(), __ffs64(), and BIT_ULL(). Note that
__ffs64() uses 0-based indexing, so the '- 1' offset is removed.
Additionally, return -ENOMEM when translation tables are exhausted to
prevent silent failure.
Signed-off-by: Sreeraj S Kurup <sreekuttan2156239@gmail.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260728122810.3475-1-sreekuttan2156239@gmail.com
|
|
This is another run of the Coccinelle script for converting kmalloc()
family of allocations to kmalloc_obj() via the existing rules in
scripts/coccinelle/api/kmalloc_objs.cocci
This catches both the set of kmalloc() uses added since the first
kmalloc_obj() conversions in v7.0 and adds a large group missed in the
first pass due to Coccinelle not interacting well with the cleanup.h
scoped_...() family of macros[1]. I worked around this with spatch's
"--macro-file" argument to a file with all the scoped_...() macros mapped
to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control
flow indicator I could find.
Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc,
riscv, and s390 with no new warnings.
Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1]
Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2]
Signed-off-by: Kees Cook <kees+treewide@kernel.org>
|
|
Zhaoxin host bridges support peer-to-peer DMA. Add their device IDs
(0x1003, 0x1005-0x1008) to the allowlist so p2pdma works on these
platforms.
The entries cover the KX-6000, KH-40000, KX-6000G, KX-7000 and KH-50000
families.
Mark the KX-6000/KH-40000/KX-6000G/KX-7000 entries REQ_SAME_HOST_BRIDGE
because P2P requests are only supported between devices below the same host
bridge. KH-50000 doesn't have this restriction.
Signed-off-by: LeoLiu-oc <leoliu-oc@zhaoxin.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260901083653.48890-1-leoliu-oc@zhaoxin.com
|
|
The RESX GPIO may be provided by a sleeping GPIO controller, such as an I2C
or SPI I/O expander. Calling gpiod_set_value() for such a GPIO triggers the
following warning:
WARNING: ... drivers/gpio/gpiolib.c:4030 at gpiod_set_value()
The TC9563 power-on and power-off callbacks already sleep while enabling or
disabling regulators and while waiting for oscillator stabilization. Use
gpiod_set_value_cansleep() for RESX so it can be driven without triggering
the warning.
Fixes: 4c9c7be47310 ("PCI: pwrctrl: Add power control driver for TC9563")
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260825-pci-pwrctl-tc9563-use-cansleep-for-resx-v1-1-0dbe7cfd8200@oss.qualcomm.com
|
|
Implement .post_deinit() callback in R-Car Gen4 'struct dw_pcie_ep_ops'
which asserts reset and stops the clock. This undoes start of clock and
deassert of reset performed in .pre_init(), in case dw_pcie_ep_init() fails
after successful call of .pre_init() callback.
The use of .post_deinit() callback correctly handles the clock and reset
unwind, unlike the call of rcar_gen4_pcie_ep_deinit() in dw_pcie_ep_init()
which could not discern at which point the dw_pcie_ep_init() failed and can
attempt to stop clock and assert reset twice.
Since dw_pcie_ep_deinit() also invokes the .post_deinit() callback, drop
calls to rcar_gen4_pcie_ep_deinit() in both rcar_gen4_add_dw_pcie_ep() and
dw_pcie_ep_init_registers() fail paths and rcar_gen4_remove_dw_pcie_ep() to
avoid duplicate stop of clock and assert of reset, and drop no longer used
rcar_gen4_pcie_ep_deinit() entirely.
Initialize PCIEDMAINTSTSEN early in rcar_gen4_pcie_ep_pre_init() to 0, to
make sure that edma_int bits will never be left set in case of failure of
dw_pcie_ep_init(), and will only be set in case dw_pcie_ep_init() succeeds.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Koichiro Den <den@valinux.co.jp>
Reviewed-by: Koichiro Den <den@valinux.co.jp>
Link: https://patch.msgid.link/20260821122808.238248-2-marek.vasut+renesas@mailbox.org
|
|
If .pre_init() succeeds but subsequent initialization fails, it is
mandatory to correctly undo the hardware configuration which the
.pre_init() callback did. Introduce a .post_deinit() callback to do exactly
that, undo what the .pre_init() callback did. Usually, that means stop the
clock, assert reset, and possibly program some registers to quiesce the
hardware. Invoke the .post_deinit() callback in dw_pcie_ep_deinit() to
retain functional symmetry.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Koichiro Den <den@valinux.co.jp>
Reviewed-by: Koichiro Den <den@valinux.co.jp>
Link: https://patch.msgid.link/20260821122808.238248-1-marek.vasut+renesas@mailbox.org
|
