<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux-stable.git/drivers/pci, branch linux-rolling-stable</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/atom?h=linux-rolling-stable</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/atom?h=linux-rolling-stable'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/'/>
<updated>2026-07-18T14:55:24+00:00</updated>
<entry>
<title>PCI/IOV: Skip VF Resizable BAR restore on read error</title>
<updated>2026-07-18T14:55:24+00:00</updated>
<author>
<name>Marco Nenciarini</name>
<email>mnencia@kcore.it</email>
</author>
<published>2026-04-17T13:24:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=55fd485e66d0ad5c762c23dba1461fe9c741cd96'/>
<id>urn:sha1:55fd485e66d0ad5c762c23dba1461fe9c741cd96</id>
<content type='text'>
commit f34f1712229d71ce4286440fef12526fd4590b37 upstream.

sriov_restore_vf_rebar_state() uses the VF Resizable BAR Control register
to decide how many VF BARs to restore (nbars) and which VF BAR each
iteration addresses (bar_idx). bar_idx indexes into dev-&gt;sriov-&gt;barsz[],
which has only PCI_SRIOV_NUM_BARS (6) entries.

When a device does not respond, config reads typically return
PCI_ERROR_RESPONSE (~0).  Both fields are 3 bits wide, so nbars and bar_idx
both evaluate to 7. The barsz[] access then goes out of bounds.  UBSAN
reports this as:

  UBSAN: array-index-out-of-bounds in drivers/pci/iov.c:948:51 index 7 is out of range for type 'resource_size_t [6]'

Observed on an NVIDIA RTX PRO 1000 GPU (GB207GLM) that stopped responding
during a failed GC6 power state exit. The subsequent pci_restore_state()
invoked sriov_restore_vf_rebar_state() while config reads returned
0xffffffff, triggering the splat.

Bail out if any VF Resizable BAR Control read returns PCI_ERROR_RESPONSE.
No further VF BARs are touched, which is safe because a config read that
returns PCI_ERROR_RESPONSE indicates the device is unreachable and
restoration is pointless. This mirrors the guard in
pci_restore_rebar_state().

Fixes: 5a8f77e24a30 ("PCI/IOV: Restore VF resizable BAR state after reset")
Signed-off-by: Marco Nenciarini &lt;mnencia@kcore.it&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/44a4ae53ec2825816b816c85cd378430d9a95cc6.1776429882.git.mnencia@kcore.it
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>PCI: Skip Resizable BAR restore on read error</title>
<updated>2026-07-18T14:55:24+00:00</updated>
<author>
<name>Marco Nenciarini</name>
<email>mnencia@kcore.it</email>
</author>
<published>2026-04-17T13:24:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=7908ddb6f8b3e77df191d2fda3969ecfce4538e9'/>
<id>urn:sha1:7908ddb6f8b3e77df191d2fda3969ecfce4538e9</id>
<content type='text'>
commit ee7471fe968d210939be9046089a924cd23c8c3b upstream.

pci_restore_rebar_state() uses the Resizable BAR Control register to decide
how many BARs to restore (nbars) and which BAR each iteration addresses
(bar_idx).

When a device does not respond, config reads typically return
PCI_ERROR_RESPONSE (~0).  Both fields are 3 bits wide, so nbars and bar_idx
both evaluate to 7, past the spec's valid ranges for both fields.
pci_resource_n() then returns an unrelated resource slot, whose size is
used to derive a nonsensical value written back to the Resizable BAR
Control register.

Bail out if any Resizable BAR Control read returns PCI_ERROR_RESPONSE. No
further BARs are touched, which is safe because a config read that returns
PCI_ERROR_RESPONSE indicates the device is unreachable and restoration is
pointless.

Fixes: d3252ace0bc6 ("PCI: Restore resized BAR state on resume")
Signed-off-by: Marco Nenciarini &lt;mnencia@kcore.it&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/666cac19b5daa0ab0e0ab64454e76b4d24465dbd.1776429882.git.mnencia@kcore.it
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>PCI: qcom: Initialize DWC MSI lock for firmware-managed ECAM hosts</title>
<updated>2026-07-18T14:55:24+00:00</updated>
<author>
<name>Yadu M G</name>
<email>yadu.mg@oss.qualcomm.com</email>
</author>
<published>2026-06-04T12:24:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=67a8b1d876d5a7990e0d23a3510df013a50f5376'/>
<id>urn:sha1:67a8b1d876d5a7990e0d23a3510df013a50f5376</id>
<content type='text'>
commit e0779713a1e2f891aeec53e629dbbd33f423c629 upstream.

A lockdep warning is observed during boot on a Qcom firmware-managed
platform:

  INFO: trying to register non-static key.
  The code is fine but needs lockdep annotation, or maybe
  you didn't initialize this object before use?
  turning off the locking correctness validator.
  ...
  Call trace:
   register_lock_class+0x128/0x4d8
   __lock_acquire+0x110/0x1db0
   lock_acquire+0x278/0x3d8
   _raw_spin_lock_irq+0x6c/0xc0
   dw_pcie_irq_domain_alloc+0x48/0x190
   irq_domain_alloc_irqs_parent+0x2c/0x48
   msi_domain_alloc+0x90/0x160
  ...

dw_pcie_irq_domain_alloc() takes pp-&gt;lock while allocating MSI
interrupts. pp-&gt;lock is normally initialized by dw_pcie_host_init(), but
Qcom firmware-managed hosts use the ECAM init path instead:

  pci_host_common_ecam_create()
    pci_ecam_create()
      qcom_pcie_ecam_host_init()
        dw_pcie_msi_host_init()
          dw_pcie_allocate_domains()

That path constructs a fresh struct dw_pcie_rp and calls
dw_pcie_msi_host_init() directly, without going through
dw_pcie_host_init(). As a result, pp-&gt;lock was not initialized, which
triggers the warning.

Initialize pp-&gt;lock in qcom_pcie_ecam_host_init() before registering the
MSI domains so the firmware-managed ECAM path matches the normal DWC host
initialization sequence.

Fixes: 7d944c0f1469 ("PCI: qcom: Add support for Qualcomm SA8255p based PCIe Root Complex")
Signed-off-by: Yadu M G &lt;yadu.mg@oss.qualcomm.com&gt;
[mani: added fixes tag and CCed stable]
Signed-off-by: Manivannan Sadhasivam &lt;mani@kernel.org&gt;
Cc: stable@kernel.org
Link: https://patch.msgid.link/20260604122418.727274-1-yadu.mg@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>PCI: mediatek: Fix IRQ domain leak when port fails to enable</title>
<updated>2026-07-18T14:55:24+00:00</updated>
<author>
<name>Manivannan Sadhasivam</name>
<email>manivannan.sadhasivam@oss.qualcomm.com</email>
</author>
<published>2026-05-21T17:46:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=df77314b3bedbd9ad5d6f0682f98b99e3c5f7e2e'/>
<id>urn:sha1:df77314b3bedbd9ad5d6f0682f98b99e3c5f7e2e</id>
<content type='text'>
commit f865a57896bd92d7662eb2818d8f48872e2cbbc7 upstream.

When mtk_pcie_enable_port() fails, mtk_pcie_port_free() removes the port
from pcie-&gt;ports and frees the port structure. However, the IRQ domains set
up earlier by mtk_pcie_init_irq_domain() are never freed.

Fix this by refactoring mtk_pcie_irq_teardown() into a per-port helper,
mtk_pcie_irq_teardown_port(), and calling it from mtk_pcie_setup() when
mtk_pcie_enable_port() fails. Since the IRQ teardown must only happen in
the probe error path (during resume, child devices may have active MSI
mappings and the NOIRQ context prohibits sleeping locks),
mtk_pcie_enable_port() is changed to return an error code so callers can
distinguish the two paths and act accordingly.

This issue was reported by Sashiko while reviewing the EcoNet EN7528 SoC
support series.

Fixes: b099631df160 ("PCI: mediatek: Add controller support for MT2712 and MT7622")
Signed-off-by: Manivannan Sadhasivam &lt;manivannan.sadhasivam@oss.qualcomm.com&gt;
Signed-off-by: Manivannan Sadhasivam &lt;mani@kernel.org&gt;
Cc: stable@vger.kernel.org # 5.10
Cc: Caleb James DeLisle &lt;cjd@cjdns.fr&gt;
Link: https://patch.msgid.link/20260521174617.17692-1-mani@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>PCI: imx6: Assert ref_clk_en after reference clock stabilizes on i.MX95</title>
<updated>2026-07-18T14:55:24+00:00</updated>
<author>
<name>Richard Zhu</name>
<email>hongxing.zhu@nxp.com</email>
</author>
<published>2026-05-18T07:27:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=6a2363bf9eae1fedbd35a28c66f97c85899b8a3e'/>
<id>urn:sha1:6a2363bf9eae1fedbd35a28c66f97c85899b8a3e</id>
<content type='text'>
commit 9dda3f83ba677b9cc2613cecd9120123000ae50f upstream.

According to the PHY Databook Common Block Signals section, the
ref_clk_en signal must remain de-asserted until the reference clock is
running at the appropriate frequency. Once the clock is stable,
ref_clk_en can be asserted. For lower power states where the reference
clock to the PHY is disabled, ref_clk_en should also be de-asserted.

Move the ref_clk_en bit manipulation into imx95_pcie_enable_ref_clk()
to ensure the reference clock stabilizes before ref_clk_en is asserted
and before the PHY reset is de-asserted. This aligns with the timing
requirements specified in the PHY documentation.

Fixes: d8574ce57d76 ("PCI: imx6: Add external reference clock input mode support")
Signed-off-by: Richard Zhu &lt;hongxing.zhu@nxp.com&gt;
Signed-off-by: Manivannan Sadhasivam &lt;mani@kernel.org&gt;
Reviewed-by: Frank Li &lt;Frank.Li@nxp.com&gt;
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260518072715.3166514-3-hongxing.zhu@nxp.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>PCI: imx6: Fix IMX6SX_GPR12_PCIE_TEST_POWERDOWN handling</title>
<updated>2026-07-18T14:55:24+00:00</updated>
<author>
<name>Richard Zhu</name>
<email>hongxing.zhu@nxp.com</email>
</author>
<published>2026-03-19T09:08:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=edefa5f4b70159f90162b2b9982c12c98fbd0479'/>
<id>urn:sha1:edefa5f4b70159f90162b2b9982c12c98fbd0479</id>
<content type='text'>
commit aad953fb4eed0df5486cd54ccad80ac197678e01 upstream.

The IMX6SX_GPR12_PCIE_TEST_POWERDOWN bit does not control the PCIe
reference clock on i.MX6SX. Instead, it is part of i.MX6SX PCIe core
reset sequence.

Move the IMX6SX_GPR12_PCIE_TEST_POWERDOWN assertion/deassertion into
the core reset functions to properly reflect its purpose. Remove the
.enable_ref_clk() callback for i.MX6SX since it was incorrectly
manipulating this bit.

Fixes: e3c06cd063d6 ("PCI: imx6: Add initial imx6sx support")
Signed-off-by: Richard Zhu &lt;hongxing.zhu@nxp.com&gt;
Signed-off-by: Manivannan Sadhasivam &lt;mani@kernel.org&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Frank Li &lt;Frank.Li@nxp.com&gt;
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260319090844.444987-1-hongxing.zhu@nxp.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>PCI: imx6: Configure REF_USE_PAD before PHY reset for i.MX95</title>
<updated>2026-07-18T14:55:24+00:00</updated>
<author>
<name>Richard Zhu</name>
<email>hongxing.zhu@nxp.com</email>
</author>
<published>2026-05-18T07:27:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=76143cbb18dcb085d1cfcb4a71b6a03b050713ed'/>
<id>urn:sha1:76143cbb18dcb085d1cfcb4a71b6a03b050713ed</id>
<content type='text'>
commit 0c26b1c34d12d4debfb5363cc0be6cdf68e87ba2 upstream.

According to the i.MX95 PCIe PHY Databook, the ref_use_pad signal in the
Common Block Signals section selects the reference clock source connected
to the PHY pads. Per the specification, any change to this input must be
followed by a PHY reset assertion to take effect.

Move the REF_USE_PAD configuration before the PHY reset toggle to comply
with the required initialization sequence.

Fixes: 47f54a902dcd ("PCI: imx6: Toggle the core reset for i.MX95 PCIe")
Signed-off-by: Richard Zhu &lt;hongxing.zhu@nxp.com&gt;
[mani: renamed the callback and helper to match the usecase]
Signed-off-by: Manivannan Sadhasivam &lt;mani@kernel.org&gt;
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260518072715.3166514-2-hongxing.zhu@nxp.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>PCI: host-common: Request bus reassignment when not probe-only</title>
<updated>2026-07-18T14:55:24+00:00</updated>
<author>
<name>Ratheesh Kannoth</name>
<email>rkannoth@marvell.com</email>
</author>
<published>2026-04-14T08:17:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=7707ac040967e4da2fc65ae578f1d3e8c8307621'/>
<id>urn:sha1:7707ac040967e4da2fc65ae578f1d3e8c8307621</id>
<content type='text'>
commit fda8749ba73638f5bbca3ffb39bc6861eb3b23fa upstream.

pci_host_common_init() is used by several generic ECAM host drivers.
After PCI core changes around pci_flags and preserve_config, these hosts
no longer opted into full bus number reassignment the way they did
before, which broke enumeration of devices on a Marvell CN106XX board.

When PCI_PROBE_ONLY is not set, add PCI_REASSIGN_ALL_BUS so
pci_scan_bridge_extend() takes the reassignment path: bus numbers can be
assigned from firmware EA data (e.g. pci_ea_fixed_busnrs()). Skip the
flag in probe-only mode so existing assignments are not overridden.

Fixes: 7246a4520b4b ("PCI: Use preserve_config in place of pci_flags")
Closes: https://lore.kernel.org/all/abkqm_LCd9zAM8cW@rkannoth-OptiPlex-7090/
Signed-off-by: Ratheesh Kannoth &lt;rkannoth@marvell.com&gt;
[mani: added stable tag]
Signed-off-by: Manivannan Sadhasivam &lt;mani@kernel.org&gt;
[bhelgaas: add problem report link]
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Cc: stable@vger.kernel.org
Cc: Vidya Sagar &lt;vidyas@nvidia.com&gt;
Link: https://patch.msgid.link/20260414081730.3864372-1-rkannoth@marvell.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining</title>
<updated>2026-07-18T14:55:24+00:00</updated>
<author>
<name>Maciej W. Rozycki</name>
<email>macro@orcam.me.uk</email>
</author>
<published>2025-12-08T19:24:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=669c4f38760080919db88343228a07e8ed7267c3'/>
<id>urn:sha1:669c4f38760080919db88343228a07e8ed7267c3</id>
<content type='text'>
commit 72780f7964684939d7d2f69c348876213b184484 upstream.

Discard Vendor:Device ID matching in the PCIe failed link retraining quirk
and ignore the link status for the removal of the 2.5GT/s speed clamp,
whether applied by the quirk itself or the firmware earlier on.  Revert to
the original target link speed if this final link retraining has failed.

This is so that link training noise in hot-plug scenarios does not make a
link remain clamped to the 2.5GT/s speed where an event race has led the
quirk to apply the speed clamp for one device, only to leave it in place
for a subsequent device to be plugged in.

Refer to the Link Capabilities register directly for the maximum link speed
determination so as to streamline backporting.

Fixes: a89c82249c37 ("PCI: Work around PCIe link training failures")
Signed-off-by: Maciej W. Rozycki &lt;macro@orcam.me.uk&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Tested-by: Alok Tiwari &lt;alok.a.tiwari@oracle.com&gt;
Cc: stable@vger.kernel.org # v6.5+
Link: https://patch.msgid.link/alpine.DEB.2.21.2512080331530.49654@angie.orcam.me.uk
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>PCI: altera: Fix resource leaks on probe failure</title>
<updated>2026-07-18T14:55:24+00:00</updated>
<author>
<name>Mahesh Vaidya</name>
<email>mahesh.vaidya@altera.com</email>
</author>
<published>2026-04-30T20:43:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=6864c789b570e57f932847fa83f6b56917182d73'/>
<id>urn:sha1:6864c789b570e57f932847fa83f6b56917182d73</id>
<content type='text'>
commit 7a94138caeb27f3c49c1dbd93bf422098925bb28 upstream.

The chained IRQ handler is set during probe, but is only removed during the
driver remove(). If pci_host_probe() fails, the handler and INTx IRQ
domain remain set even though the devm-managed host bridge storage
containing struct altera_pcie will be released, leaving the handler with
a stale data pointer.

Interrupts are also enabled before pci_host_probe() is called. If probe
fails after that point, the controller interrupt source should be disabled
before the chained handler and INTx domain are removed.

So set the chained handler only after the INTx domain has been created.
Disable controller interrupts during IRQ teardown, and tear the IRQ setup
down if pci_host_probe() fails.

Fixes: c63aed7334c2 ("PCI: altera: Use pci_host_probe() to register host")
Signed-off-by: Mahesh Vaidya &lt;mahesh.vaidya@altera.com&gt;
[mani: commit log]
Signed-off-by: Manivannan Sadhasivam &lt;mani@kernel.org&gt;
Reviewed-by: Subhransu S. Prusty &lt;subhransu.sekhar.prusty@altera.com&gt;
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260430204330.3121003-3-mahesh.vaidya@altera.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
