<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux-stable.git/drivers/pci, branch linux-6.18.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/atom?h=linux-6.18.y</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/atom?h=linux-6.18.y'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/'/>
<updated>2026-07-18T14:53:13+00:00</updated>
<entry>
<title>PCI/IOV: Skip VF Resizable BAR restore on read error</title>
<updated>2026-07-18T14:53:13+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=b77524621250407386f44c6eea7e5e4619ada1ce'/>
<id>urn:sha1:b77524621250407386f44c6eea7e5e4619ada1ce</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: qcom: Initialize DWC MSI lock for firmware-managed ECAM hosts</title>
<updated>2026-07-18T14:53:13+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=1115680bca1d748ce887ec4b0ad1012714231479'/>
<id>urn:sha1:1115680bca1d748ce887ec4b0ad1012714231479</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:53:12+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=6e6a529d6f779413379b4404c9ef6a36c0337225'/>
<id>urn:sha1:6e6a529d6f779413379b4404c9ef6a36c0337225</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: Fix IMX6SX_GPR12_PCIE_TEST_POWERDOWN handling</title>
<updated>2026-07-18T14:53:12+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=69416a5308675ab6d4e22a83f14048a5cc02e9bb'/>
<id>urn:sha1:69416a5308675ab6d4e22a83f14048a5cc02e9bb</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: host-common: Request bus reassignment when not probe-only</title>
<updated>2026-07-18T14:53:12+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=1d2e66a4bc0dd6c1f6f2f28247450e4d4ce7f5ba'/>
<id>urn:sha1:1d2e66a4bc0dd6c1f6f2f28247450e4d4ce7f5ba</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:53:12+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=9c698af5c2a12035d093244ca37e3c0971fd05e4'/>
<id>urn:sha1:9c698af5c2a12035d093244ca37e3c0971fd05e4</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:53:12+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=09c43b7b7d29c6fadb27f32cdf7f3bb6598befa9'/>
<id>urn:sha1:09c43b7b7d29c6fadb27f32cdf7f3bb6598befa9</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>
<entry>
<title>PCI: altera: Do not dispose parent IRQ mapping</title>
<updated>2026-07-18T14:53:12+00:00</updated>
<author>
<name>Mahesh Vaidya</name>
<email>mahesh.vaidya@altera.com</email>
</author>
<published>2026-04-30T20:43: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=5e42a981887d24580c19bee1ba99a5292e572713'/>
<id>urn:sha1:5e42a981887d24580c19bee1ba99a5292e572713</id>
<content type='text'>
commit 5ef4bac02189bee0b7c170e352d7a38e13fe9678 upstream.

altera_pcie_irq_teardown() calls irq_dispose_mapping() on pcie-&gt;irq.
However, pcie-&gt;irq is the parent IRQ returned by platform_get_irq(), not
the mapping created by Altera INTx irq_domain.

The Altera driver only sets the chained handler on the parent IRQ. It
should detach that handler during teardown, but it should not dispose the
parent IRQ mapping, which belongs to the parent interrupt controller's
irq_domain.

Drop irq_dispose_mapping(pcie-&gt;irq) from the teardown path.

Note that during irqchip remove(), the child IRQs should've disposed. But
since the chained handler itself is removed, there is no way the stale
child IRQs (if exists) could fire. So it is safe here.

Fixes: ec15c4d0d5d2 ("PCI: altera: Allow building as module")
Signed-off-by: Mahesh Vaidya &lt;mahesh.vaidya@altera.com&gt;
[mani: added a note about IRQ disposal]
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-2-mahesh.vaidya@altera.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>PCI: loongson: Override PCIe bridge supported speeds for Loongson-3C6000 series</title>
<updated>2026-07-18T14:53:12+00:00</updated>
<author>
<name>Ziyao Li</name>
<email>liziyao@uniontech.com</email>
</author>
<published>2026-04-12T10:17:31+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=d666c5aec822d42e8a26dce29eddfdf6d154b169'/>
<id>urn:sha1:d666c5aec822d42e8a26dce29eddfdf6d154b169</id>
<content type='text'>
commit e373c789bac0ad73b472d8b44714df3bd18a4edf upstream.

Older steppings of the Loongson-3C6000 series incorrectly report the
supported link speeds on their PCIe bridges (device IDs 0x3c19, 0x3c29)
as only 2.5 GT/s, despite the upstream bus supporting speeds from
2.5 GT/s up to 16 GT/s.

As a result, since commit 774c71c52aa4 ("PCI/bwctrl: Enable only if more
than one speed is supported"), bwctrl will be disabled if there's only
one 2.5 GT/s value in vector 'supported_speeds'.

Manually override the 'supported_speeds' field for affected PCIe bridges
with those found on the upstream bus to correctly reflect the supported
link speeds.  Updating the speeds to reflect what the hardware actually
supports avoids quirks in drivers consuming the speed information.

This commit was originally found from AOSC OS[1].

Fixes: cd89edda4002 ("PCI: loongson: Add ACPI init support")
Signed-off-by: Ayden Meng &lt;aydenmeng@yeah.net&gt;
Signed-off-by: Mingcong Bai &lt;jeffbai@aosc.io&gt;
[Ziyao Li: move from drivers/pci/quirks.c to drivers/pci/controller/pci-loongson.c]
Signed-off-by: Ziyao Li &lt;liziyao@uniontech.com&gt;
[Xi Ruoyao: Fixed falling through logic, added debug log, Fixes tag and rebased to 7.0-rc7]
Signed-off-by: Xi Ruoyao &lt;xry111@xry111.site&gt;
Signed-off-by: Manivannan Sadhasivam &lt;mani@kernel.org&gt;
[bhelgaas: commit log, https://lore.kernel.org/all/9d815df3b33a63223112b97440c01247935363c1.camel@xry111.site]
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Tested-by: Lain Fearyncess Yang &lt;fsf@live.com&gt;
Tested-by: Ayden Meng &lt;aydenmeng@yeah.net&gt;
Tested-by: Mingcong Bai &lt;jeffbai@aosc.io&gt;
Reviewed-by: Huacai Chen &lt;chenhuacai@loongson.cn&gt;
Cc: stable@vger.kernel.org
Link: https://github.com/AOSC-Tracking/linux/commit/4392f441363abdf6fa0a0433d73175a17f493454
Link: https://github.com/AOSC-Tracking/linux/pull/2 #1
Link: https://patch.msgid.link/20260412101731.107059-1-xry111@xry111.site
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Revert "PCI: qcom: Advertise Hotplug Slot Capability with no Command Completion support"</title>
<updated>2026-07-04T11:44:14+00:00</updated>
<author>
<name>Sasha Levin</name>
<email>sashal@kernel.org</email>
</author>
<published>2026-06-27T14:53:39+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=671ec2eabb874fcb593297c4dd885fc3dae54f32'/>
<id>urn:sha1:671ec2eabb874fcb593297c4dd885fc3dae54f32</id>
<content type='text'>
This reverts commit f176c47683bf6365e2f6d580d557fae49169a703.

Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
