<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/pci, branch v5.15.209</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.15.209</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.15.209'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-06-01T15:35:32+00:00</updated>
<entry>
<title>PCI: tegra194: Disable direct speed change for Endpoint mode</title>
<updated>2026-06-01T15:35:32+00:00</updated>
<author>
<name>Vidya Sagar</name>
<email>vidyas@nvidia.com</email>
</author>
<published>2026-03-24T19:07:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=74ce81de32feb468fa4477bee6516ed553a4d973'/>
<id>urn:sha1:74ce81de32feb468fa4477bee6516ed553a4d973</id>
<content type='text'>
[ Upstream commit 976f6763f57970388bcd7118931f33f447916927 ]

Pre-silicon simulation showed the controller operating in Endpoint mode
initiating link speed change after completing Secondary Bus Reset. Ideally,
the Root Port or the Switch Downstream Port should initiate the link speed
change post SBR, not the Endpoint.

So, as per the hardware team recommendation, disable direct speed change
for the Endpoint mode to prevent it from initiating speed change after the
physical layer link is up at Gen1, leaving speed change ownership with the
host.

Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194")
Signed-off-by: Vidya Sagar &lt;vidyas@nvidia.com&gt;
Signed-off-by: Manikanta Maddireddy &lt;mmaddireddy@nvidia.com&gt;
[mani: commit log]
Signed-off-by: Manivannan Sadhasivam &lt;mani@kernel.org&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Reviewed-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Reviewed-by: Vidya Sagar &lt;vidyas@nvidia.com&gt;
Link: https://patch.msgid.link/20260324190755.1094879-8-mmaddireddy@nvidia.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>PCI: tegra194: Use devm_gpiod_get_optional() to parse "nvidia,refclk-select"</title>
<updated>2026-06-01T15:35:32+00:00</updated>
<author>
<name>Vidya Sagar</name>
<email>vidyas@nvidia.com</email>
</author>
<published>2026-03-24T19:07:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5e62eaf273a15c55349fd810aa963752e76527b7'/>
<id>urn:sha1:5e62eaf273a15c55349fd810aa963752e76527b7</id>
<content type='text'>
[ Upstream commit f62bc7917de1374dce86a852ffba8baf9cb7a56a ]

The GPIO DT property "nvidia,refclk-select", to select the PCIe reference
clock is optional. Use devm_gpiod_get_optional() to get it.

Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194")
Signed-off-by: Vidya Sagar &lt;vidyas@nvidia.com&gt;
Signed-off-by: Manikanta Maddireddy &lt;mmaddireddy@nvidia.com&gt;
Signed-off-by: Manivannan Sadhasivam &lt;mani@kernel.org&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Reviewed-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Reviewed-by: Vidya Sagar &lt;vidyas@nvidia.com&gt;
Link: https://patch.msgid.link/20260324190755.1094879-7-mmaddireddy@nvidia.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>PCI: tegra194: Disable LTSSM after transition to Detect on surprise link down</title>
<updated>2026-06-01T15:35:32+00:00</updated>
<author>
<name>Manikanta Maddireddy</name>
<email>mmaddireddy@nvidia.com</email>
</author>
<published>2026-03-24T19:07:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=15947c862ff25aaf53bfa648d18e54536ca12f06'/>
<id>urn:sha1:15947c862ff25aaf53bfa648d18e54536ca12f06</id>
<content type='text'>
[ Upstream commit 9fa0c242f8d7acf1b124d4462d18f4023573ac1c ]

After the link reaches a Detect-related LTSSM state, disable LTSSM so it
does not keep toggling between Polling and Detect. Do this by polling for
the Detect state first, then clearing APPL_CTRL_LTSSM_EN in both
tegra_pcie_dw_pme_turnoff() and pex_ep_event_pex_rst_assert().

Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support")
Signed-off-by: Vidya Sagar &lt;vidyas@nvidia.com&gt;
Signed-off-by: Manikanta Maddireddy &lt;mmaddireddy@nvidia.com&gt;
Signed-off-by: Manivannan Sadhasivam &lt;mani@kernel.org&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Reviewed-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Link: https://patch.msgid.link/20260324190755.1094879-4-mmaddireddy@nvidia.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>PCI: tegra194: Increase LTSSM poll time on surprise link down</title>
<updated>2026-06-01T15:35:32+00:00</updated>
<author>
<name>Manikanta Maddireddy</name>
<email>mmaddireddy@nvidia.com</email>
</author>
<published>2026-03-24T19:07:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b31250b8a85a84da891c3eae38d05936d11c5419'/>
<id>urn:sha1:b31250b8a85a84da891c3eae38d05936d11c5419</id>
<content type='text'>
[ Upstream commit 74dd8efe4d6cead433162147333af989a568aac7 ]

On surprise link down, LTSSM state transits from L0 -&gt; Recovery.RcvrLock -&gt;
Recovery.RcvrSpeed -&gt; Gen1 Recovery.RcvrLock -&gt; Detect. Recovery.RcvrLock
and Recovery.RcvrSpeed transit times are 24 ms and 48 ms respectively, so
the total time from L0 to Detect is ~96 ms. Increase the poll timeout to
120 ms to account for this.

While at it, add LTSSM state defines for Detect-related states and use them
in the poll condition. Use readl_poll_timeout() instead of
readl_poll_timeout_atomic() in tegra_pcie_dw_pme_turnoff() since that path
runs in non-atomic context.

Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support")
Signed-off-by: Vidya Sagar &lt;vidyas@nvidia.com&gt;
Signed-off-by: Manikanta Maddireddy &lt;mmaddireddy@nvidia.com&gt;
Signed-off-by: Manivannan Sadhasivam &lt;mani@kernel.org&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Reviewed-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Link: https://patch.msgid.link/20260324190755.1094879-3-mmaddireddy@nvidia.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>PCI: tegra194: Fix polling delay for L2 state</title>
<updated>2026-06-01T15:35:32+00:00</updated>
<author>
<name>Vidya Sagar</name>
<email>vidyas@nvidia.com</email>
</author>
<published>2026-03-24T19:07:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fa5d1387c076d0a948a99c0b08833581d5fcd6dc'/>
<id>urn:sha1:fa5d1387c076d0a948a99c0b08833581d5fcd6dc</id>
<content type='text'>
[ Upstream commit adaffed907f14f954096555665ad6af2ae724d83 ]

As per PCIe r7.0, sec 5.3.3.2.1, after sending PME_Turn_Off message, Root
Port should wait for 1-10 msec for PME_TO_Ack message. Currently, driver is
polling for 10 msec with 1 usec delay which is aggressive.  Use existing
macro PCIE_PME_TO_L2_TIMEOUT_US to poll for 10 msec with 1 msec delay.
Since this function is used in non-atomic context only, use non-atomic poll
function.

Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support")
Signed-off-by: Vidya Sagar &lt;vidyas@nvidia.com&gt;
Signed-off-by: Manikanta Maddireddy &lt;mmaddireddy@nvidia.com&gt;
Signed-off-by: Manivannan Sadhasivam &lt;mani@kernel.org&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Reviewed-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Link: https://patch.msgid.link/20260324190755.1094879-2-mmaddireddy@nvidia.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>PCI: Add PCIE_PME_TO_L2_TIMEOUT_US L2 ready timeout value</title>
<updated>2026-06-01T15:35:32+00:00</updated>
<author>
<name>Frank Li</name>
<email>Frank.Li@nxp.com</email>
</author>
<published>2023-08-21T18:48:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9bfdb26495d04ed75aeae32463d0f3dc7aac15ab'/>
<id>urn:sha1:9bfdb26495d04ed75aeae32463d0f3dc7aac15ab</id>
<content type='text'>
[ Upstream commit e78bd50b4078b3b2d9f85d97796b7c271e7860ca ]

Add the PCIE_PME_TO_L2_TIMEOUT_US macro to define the L2 ready timeout
as described in the PCI specifications.

Link: https://lore.kernel.org/r/20230821184815.2167131-2-Frank.Li@nxp.com
Signed-off-by: Frank Li &lt;Frank.Li@nxp.com&gt;
Signed-off-by: Lorenzo Pieralisi &lt;lpieralisi@kernel.org&gt;
Acked-by: Manivannan Sadhasivam &lt;mani@kernel.org&gt;
Stable-dep-of: adaffed907f1 ("PCI: tegra194: Fix polling delay for L2 state")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>PCI: Enable AtomicOps only if Root Port supports them</title>
<updated>2026-06-01T15:35:32+00:00</updated>
<author>
<name>Gerd Bayer</name>
<email>gbayer@linux.ibm.com</email>
</author>
<published>2026-03-30T13:09:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=84af732af42e01e101daec2d8285c3f5f8ec58b7'/>
<id>urn:sha1:84af732af42e01e101daec2d8285c3f5f8ec58b7</id>
<content type='text'>
[ Upstream commit 1ae8c4ce157037e266184064a182af9ef9af278b ]

When inspecting the config space of a Connect-X physical function in an
s390 system after it was initialized by the mlx5_core device driver, we
found the function to be enabled to request AtomicOps despite the Root Port
lacking support for completing them:

  00:00.1 Ethernet controller: Mellanox Technologies MT2894 Family [ConnectX-6 Lx]
          Subsystem: Mellanox Technologies Device 0002
          DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
                   AtomicOpsCtl: ReqEn+

On s390 and many virtualized guests, the Endpoint is visible but the Root
Port is not.  In this case, pci_enable_atomic_ops_to_root() previously
enabled AtomicOps in the Endpoint even though it can't tell whether the
Root Port supports them as a completer.

Change pci_enable_atomic_ops_to_root() to fail if there's no Root Port or
the Root Port doesn't support AtomicOps.

Fixes: 430a23689dea ("PCI: Add pci_enable_atomic_ops_to_root()")
Reported-by: Alexander Schmidt &lt;alexs@linux.ibm.com&gt;
Signed-off-by: Gerd Bayer &lt;gbayer@linux.ibm.com&gt;
[bhelgaas: commit log, check RP first to simplify flow]
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Link: https://patch.msgid.link/20260330-fix_pciatops-v7-2-f601818417e8@linux.ibm.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>PCI/AER: Stop ruling out unbound devices as error source</title>
<updated>2026-06-01T15:35:23+00:00</updated>
<author>
<name>Lukas Wunner</name>
<email>lukas@wunner.de</email>
</author>
<published>2026-03-27T09:56:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e5b98f45d9a6d9cc22c258df000c98bd8c736f8d'/>
<id>urn:sha1:e5b98f45d9a6d9cc22c258df000c98bd8c736f8d</id>
<content type='text'>
commit 1ab4a3c805084d752ec571efc78272295a9f2f74 upstream.

When searching for the error source, the AER driver rules out devices whose
enable_cnt is zero.  This was introduced in 2009 by commit 28eb27cf0839
("PCI AER: support invalid error source IDs") without providing a
rationale.

Drivers typically call pci_enable_device() on probe, hence the enable_cnt
check essentially filters out unbound devices.  At the time of the commit,
drivers had to opt in to AER by calling pci_enable_pcie_error_reporting()
and so any AER-enabled device could be assumed to be bound to a driver.
The check thus made sense because it allowed skipping config space accesses
to devices which were known not to be the error source.

But since 2022, AER is universally enabled on all devices when they are
enumerated, cf. commit f26e58bf6f54 ("PCI/AER: Enable error reporting when
AER is native").

Errors may very well be reported by unbound devices, e.g. due to link
instability.  By ruling them out as error source, errors reported by them
are neither logged nor cleared.  When they do get bound and another error
occurs, the earlier error is reported together with the new error, which
may confuse users.  Stop doing so.

Fixes: f26e58bf6f54 ("PCI/AER: Enable error reporting when AER is native")
Signed-off-by: Lukas Wunner &lt;lukas@wunner.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Stefan Roese &lt;stefan.roese@mailbox.org&gt;
Cc: stable@vger.kernel.org # v6.0+
Link: https://patch.msgid.link/734338c2e8b669db5a5a3b45d34131b55ffebfca.1774605029.git.lukas@wunner.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>PCI/AER: Clear only error bits in PCIe Device Status</title>
<updated>2026-06-01T15:35:23+00:00</updated>
<author>
<name>Shuai Xue</name>
<email>xueshuai@linux.alibaba.com</email>
</author>
<published>2026-02-11T12:46:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1d595fbea14e5ef3b271f25c5333546c991df6aa'/>
<id>urn:sha1:1d595fbea14e5ef3b271f25c5333546c991df6aa</id>
<content type='text'>
commit a8aeea1bf3c80cc87983689e0118770e019bd4f3 upstream.

Currently, pcie_clear_device_status() clears the entire PCIe Device Status
register (PCI_EXP_DEVSTA) by writing back the value read from the register,
which affects not only the error status bits but also other writable bits.

According to PCIe r7.0, sec 7.5.3.5, this register contains:

  - RW1C error status bits (CED, NFED, FED, URD at bits 0-3): These are the
    four error status bits that need to be cleared.

  - Read-only bits (AUXPD at bit 4, TRPND at bit 5): Writing to these has
    no effect.

  - Emergency Power Reduction Detected (bit 6): A RW1C non-error bit
    introduced in PCIe r5.0 (2019). This is currently the only writable
    non-error bit in the Device Status register. Unconditionally clearing
    this bit can interfere with other software components that rely on this
    power management indication.

  - Reserved bits (RsvdZ): These bits are required to be written as zero.
    Writing 1s to them (as the current implementation may do) violates the
    specification.

To prevent unintended side effects, modify pcie_clear_device_status() to
only write 1s to the four error status bits (CED, NFED, FED, URD), leaving
the Emergency Power Reduction Detected bit and reserved bits unaffected.

Fixes: ec752f5d54d7 ("PCI/AER: Clear device status bits during ERR_FATAL and ERR_NONFATAL")
Suggested-by: Lukas Wunner &lt;lukas@wunner.de&gt;
Signed-off-by: Shuai Xue &lt;xueshuai@linux.alibaba.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Kuppuswamy Sathyanarayanan &lt;sathyanarayanan.kuppuswamy@linux.intel.com&gt;
Reviewed-by: Lukas Wunner &lt;lukas@wunner.de&gt;
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260211124624.49656-1-xueshuai@linux.alibaba.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>PCI: endpoint: pci-epf-ntb: Remove duplicate resource teardown</title>
<updated>2026-06-01T15:35:14+00:00</updated>
<author>
<name>Koichiro Den</name>
<email>den@valinux.co.jp</email>
</author>
<published>2026-02-26T08:41:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c3029721b84f59e790285ad27544ed5d3cb0f2a6'/>
<id>urn:sha1:c3029721b84f59e790285ad27544ed5d3cb0f2a6</id>
<content type='text'>
commit 3446beddba450c8d6f9aca2f028712ac527fead3 upstream.

epf_ntb_epc_destroy() duplicates the teardown that the caller is
supposed to do later. This leads to an oops when .allow_link fails or
when .drop_link is performed. Remove the helper.

Also drop pci_epc_put(). EPC device refcounting is tied to configfs EPC
group lifetime, and pci_epc_put() in the .drop_link path is sufficient.

Fixes: 8b821cf76150 ("PCI: endpoint: Add EP function driver to provide NTB functionality")
Signed-off-by: Koichiro Den &lt;den@valinux.co.jp&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/20260226084142.2226875-3-den@valinux.co.jp
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
