<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/pci, branch linux-6.4.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.4.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.4.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2023-09-13T07:48:41Z</updated>
<entry>
<title>Revert "PCI: Mark NVIDIA T4 GPUs to avoid bus reset"</title>
<updated>2023-09-13T07:48:41Z</updated>
<author>
<name>Bjorn Helgaas</name>
</author>
<published>2023-09-08T19:55:30Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=93cb3211912ee510b74818737cab2f3e2f2cf5db'/>
<id>urn:sha1:93cb3211912ee510b74818737cab2f3e2f2cf5db</id>
<content type='text'>
commit 5260bd6d36c83c5b269c33baaaf8c78e520908b0 upstream.

This reverts commit d5af729dc2071273f14cbb94abbc60608142fd83.

d5af729dc207 ("PCI: Mark NVIDIA T4 GPUs to avoid bus reset") avoided
Secondary Bus Reset on the T4 because the reset seemed to not work when the
T4 was directly attached to a Root Port.

But NVIDIA thinks the issue is probably related to some issue with the Root
Port, not with the T4.  The T4 provides neither PM nor FLR reset, so
masking bus reset compromises this device for assignment scenarios.

Revert d5af729dc207 as requested by Wu Zongyong.  This will leave SBR
broken in the specific configuration Wu tested, as it was in v6.5, so Wu
will debug that further.

Link: https://lore.kernel.org/r/ZPqMCDWvITlOLHgJ@wuzongyong-alibaba
Link: https://lore.kernel.org/r/20230908201104.GA305023@bhelgaas
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>PCI/PM: Only read PCI_PM_CTRL register when available</title>
<updated>2023-09-13T07:48:40Z</updated>
<author>
<name>Feiyang Chen</name>
</author>
<published>2023-08-24T01:37:38Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b05d301ad46d2b85dfdf731c9a4a217b80cfd70a'/>
<id>urn:sha1:b05d301ad46d2b85dfdf731c9a4a217b80cfd70a</id>
<content type='text'>
commit 5694ba13b004eea683c6d4faeb6d6e7a9636bda0 upstream.

For a device with no Power Management Capability, pci_power_up() previously
returned 0 (success) if the platform was able to put the device in D0,
which led to pci_set_full_power_state() trying to read PCI_PM_CTRL, even
though it doesn't exist.

Since dev-&gt;pm_cap == 0 in this case, pci_set_full_power_state() actually
read the wrong register, interpreted it as PCI_PM_CTRL, and corrupted
dev-&gt;current_state.  This led to messages like this in some cases:

  pci 0000:01:00.0: Refused to change power state from D3hot to D0

To prevent this, make pci_power_up() always return a negative failure code
if the device lacks a Power Management Capability, even if non-PCI platform
power management has been able to put the device in D0.  The failure will
prevent pci_set_full_power_state() from trying to access PCI_PM_CTRL.

Fixes: e200904b275c ("PCI/PM: Split pci_power_up()")
Link: https://lore.kernel.org/r/20230824013738.1894965-1-chenfeiyang@loongson.cn
Signed-off-by: Feiyang Chen &lt;chenfeiyang@loongson.cn&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: "Rafael J. Wysocki" &lt;rafael@kernel.org&gt;
Cc: stable@vger.kernel.org	# v5.19+
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>PCI: hv: Fix a crash in hv_pci_restore_msi_msg() during hibernation</title>
<updated>2023-09-13T07:48:40Z</updated>
<author>
<name>Dexuan Cui</name>
</author>
<published>2023-08-16T17:59:39Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d0687755407b21d252b98dca6be459153a60c62a'/>
<id>urn:sha1:d0687755407b21d252b98dca6be459153a60c62a</id>
<content type='text'>
commit 04bbe863241a9be7d57fb4cf217ee4a72f480e70 upstream.

When a Linux VM with an assigned PCI device runs on Hyper-V, if the PCI
device driver is not loaded yet (i.e. MSI-X/MSI is not enabled on the
device yet), doing a VM hibernation triggers a panic in
hv_pci_restore_msi_msg() -&gt; msi_lock_descs(&amp;pdev-&gt;dev), because
pdev-&gt;dev.msi.data is still NULL.

Avoid the panic by checking if MSI-X/MSI is enabled.

Link: https://lore.kernel.org/r/20230816175939.21566-1-decui@microsoft.com
Fixes: dc2b453290c4 ("PCI: hv: Rework MSI handling")
Signed-off-by: Dexuan Cui &lt;decui@microsoft.com&gt;
Signed-off-by: Lorenzo Pieralisi &lt;lpieralisi@kernel.org&gt;
Reviewed-by: sathyanarayanan.kuppuswamy@linux.intel.com
Reviewed-by: Michael Kelley &lt;mikelley@microsoft.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>PCI: Free released resource after coalescing</title>
<updated>2023-09-13T07:48:40Z</updated>
<author>
<name>Ross Lagerwall</name>
</author>
<published>2023-09-06T11:08:46Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a076e73dd6e619729e1af8d0d802fe52ac5eb2b3'/>
<id>urn:sha1:a076e73dd6e619729e1af8d0d802fe52ac5eb2b3</id>
<content type='text'>
commit 8ec9c1d5d0a5a4744516adb483b97a238892f9d5 upstream.

release_resource() doesn't actually free the resource or resource list
entry so free the resource list entry to avoid a leak.

Closes: https://lore.kernel.org/r/878r9sga1t.fsf@kernel.org/
Fixes: e54223275ba1 ("PCI: Release resource invalidated by coalescing")
Link: https://lore.kernel.org/r/20230906110846.225369-1-ross.lagerwall@citrix.com
Reported-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Tested-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Signed-off-by: Ross Lagerwall &lt;ross.lagerwall@citrix.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Cc: stable@vger.kernel.org      # v5.16+
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>PCI: rockchip: Use 64-bit mask on MSI 64-bit PCI address</title>
<updated>2023-09-13T07:48:38Z</updated>
<author>
<name>Rick Wertenbroek</name>
</author>
<published>2023-07-03T08:58:45Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=20d1e215c945b5117522c23385b8031d6f19c882'/>
<id>urn:sha1:20d1e215c945b5117522c23385b8031d6f19c882</id>
<content type='text'>
commit cdb50033dd6dfcf02ae3d4ee56bc1a9555be6d36 upstream.

A 32-bit mask was used on the 64-bit PCI address used for mapping MSIs.
This would result in the upper 32 bits being unintentionally zeroed and
MSIs getting mapped to incorrect PCI addresses if the address had any
of the upper bits set.

Replace 32-bit mask by appropriate 64-bit mask.

[kwilczynski: use GENMASK_ULL() over GENMASK() for 32-bit compatibility]
Fixes: dc73ed0f1b8b ("PCI: rockchip: Fix window mapping and address translation for endpoint")
Closes: https://lore.kernel.org/linux-pci/8d19e5b7-8fa0-44a4-90e2-9bb06f5eb694@moroto.mountain
Link: https://lore.kernel.org/linux-pci/20230703085845.2052008-1-rick.wertenbroek@gmail.com
Reported-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Signed-off-by: Rick Wertenbroek &lt;rick.wertenbroek@gmail.com&gt;
Signed-off-by: Krzysztof Wilczyński &lt;kwilczynski@kernel.org&gt;
Reviewed-by: Damien Le Moal &lt;dlemoal@kernel.org&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>PCI/ASPM: Use RMW accessors for changing LNKCTL</title>
<updated>2023-09-13T07:48:22Z</updated>
<author>
<name>Ilpo Järvinen</name>
</author>
<published>2023-07-17T12:04:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=49a9ac827052e6893df3b7c36985a174f9d1b6a8'/>
<id>urn:sha1:49a9ac827052e6893df3b7c36985a174f9d1b6a8</id>
<content type='text'>
[ Upstream commit e09060b3b6b4661278ff8e1b7b81a37d5ea86eae ]

Don't assume that the device is fully under the control of ASPM and use RMW
capability accessors which do proper locking to avoid losing concurrent
updates to the register values.

If configuration fails in pcie_aspm_configure_common_clock(), the
function attempts to restore the old PCI_EXP_LNKCTL_CCC settings. Store
only the old PCI_EXP_LNKCTL_CCC bit for the relevant devices rather
than the content of the whole LNKCTL registers. It aligns better with
how pcie_lnkctl_clear_and_set() expects its parameter and makes the
code more obvious to understand.

Suggested-by: Lukas Wunner &lt;lukas@wunner.de&gt;
Fixes: 2a42d9dba784 ("PCIe: ASPM: Break out of endless loop waiting for PCI config bits to switch")
Fixes: 7d715a6c1ae5 ("PCI: add PCI Express ASPM support")
Link: https://lore.kernel.org/r/20230717120503.15276-5-ilpo.jarvinen@linux.intel.com
Signed-off-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: "Rafael J. Wysocki" &lt;rafael@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>PCI: pciehp: Use RMW accessors for changing LNKCTL</title>
<updated>2023-09-13T07:48:22Z</updated>
<author>
<name>Ilpo Järvinen</name>
</author>
<published>2023-07-17T12:04:55Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9d31c101cc3eeb9a5d8c8d60f6639fad4c917a5f'/>
<id>urn:sha1:9d31c101cc3eeb9a5d8c8d60f6639fad4c917a5f</id>
<content type='text'>
[ Upstream commit 5f75f96c61039151c193775d776fde42477eace1 ]

As hotplug is not the only driver touching LNKCTL, use the RMW capability
accessor which handles concurrent changes correctly.

Suggested-by: Lukas Wunner &lt;lukas@wunner.de&gt;
Fixes: 7f822999e12a ("PCI: pciehp: Add Disable/enable link functions")
Link: https://lore.kernel.org/r/20230717120503.15276-4-ilpo.jarvinen@linux.intel.com
Signed-off-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: "Rafael J. Wysocki" &lt;rafael@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>PCI: Add locking to RMW PCI Express Capability Register accessors</title>
<updated>2023-09-13T07:48:22Z</updated>
<author>
<name>Ilpo Järvinen</name>
</author>
<published>2023-07-17T12:04:53Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=df666f21768b3993490cbbb5c089b786ea686a96'/>
<id>urn:sha1:df666f21768b3993490cbbb5c089b786ea686a96</id>
<content type='text'>
[ Upstream commit 5e70d0acf0825f439079736080350371f8d6699a ]

Many places in the kernel write the Link Control and Root Control PCI
Express Capability Registers without proper concurrency control and this
could result in losing the changes one of the writers intended to make.

Add pcie_cap_lock spinlock into the struct pci_dev and use it to protect
bit changes made in the RMW capability accessors. Protect only a selected
set of registers by differentiating the RMW accessor internally to
locked/unlocked variants using a wrapper which has the same signature as
pcie_capability_clear_and_set_word(). As the Capability Register (pos)
given to the wrapper is always a constant, the compiler should be able to
simplify all the dead-code away.

So far only the Link Control Register (ASPM, hotplug, link retraining,
various drivers) and the Root Control Register (AER &amp; PME) seem to
require RMW locking.

Suggested-by: Lukas Wunner &lt;lukas@wunner.de&gt;
Fixes: c7f486567c1d ("PCI PM: PCIe PME root port service driver")
Fixes: f12eb72a268b ("PCI/ASPM: Use PCI Express Capability accessors")
Fixes: 7d715a6c1ae5 ("PCI: add PCI Express ASPM support")
Fixes: affa48de8417 ("staging/rdma/hfi1: Add support for enabling/disabling PCIe ASPM")
Fixes: 849a9366cba9 ("misc: rtsx: Add support new chip rts5228 mmc: rtsx: Add support MMC_CAP2_NO_MMC")
Fixes: 3d1e7aa80d1c ("misc: rtsx: Use pcie_capability_clear_and_set_word() for PCI_EXP_LNKCTL")
Fixes: c0e5f4e73a71 ("misc: rtsx: Add support for RTS5261")
Fixes: 3df4fce739e2 ("misc: rtsx: separate aspm mode into MODE_REG and MODE_CFG")
Fixes: 121e9c6b5c4c ("misc: rtsx: modify and fix init_hw function")
Fixes: 19f3bd548f27 ("mfd: rtsx: Remove LCTLR defination")
Fixes: 773ccdfd9cc6 ("mfd: rtsx: Read vendor setting from config space")
Fixes: 8275b77a1513 ("mfd: rts5249: Add support for RTS5250S power saving")
Fixes: 5da4e04ae480 ("misc: rtsx: Add support for RTS5260")
Fixes: 0f49bfbd0f2e ("tg3: Use PCI Express Capability accessors")
Fixes: 5e7dfd0fb94a ("tg3: Prevent corruption at 10 / 100Mbps w CLKREQ")
Fixes: b726e493e8dc ("r8169: sync existing 8168 device hardware start sequences with vendor driver")
Fixes: e6de30d63eb1 ("r8169: more 8168dp support.")
Fixes: 8a06127602de ("Bluetooth: hci_bcm4377: Add new driver for BCM4377 PCIe boards")
Fixes: 6f461f6c7c96 ("e1000e: enable/disable ASPM L0s and L1 and ERT according to hardware errata")
Fixes: 1eae4eb2a1c7 ("e1000e: Disable L1 ASPM power savings for 82573 mobile variants")
Fixes: 8060e169e02f ("ath9k: Enable extended synch for AR9485 to fix L0s recovery issue")
Fixes: 69ce674bfa69 ("ath9k: do btcoex ASPM disabling at initialization time")
Fixes: f37f05503575 ("mt76: mt76x2e: disable pcie_aspm by default")
Link: https://lore.kernel.org/r/20230717120503.15276-2-ilpo.jarvinen@linux.intel.com
Signed-off-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: "Rafael J. Wysocki" &lt;rafael@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>PCI: Mark NVIDIA T4 GPUs to avoid bus reset</title>
<updated>2023-09-13T07:48:21Z</updated>
<author>
<name>Wu Zongyong</name>
</author>
<published>2023-04-10T12:34:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7da44f84c4fa626d3bca91d8d5f7e569a3f48931'/>
<id>urn:sha1:7da44f84c4fa626d3bca91d8d5f7e569a3f48931</id>
<content type='text'>
[ Upstream commit d5af729dc2071273f14cbb94abbc60608142fd83 ]

NVIDIA T4 GPUs do not work with SBR. This problem is found when the T4 card
is direct attached to a Root Port only. Avoid bus reset by marking T4 GPUs
PCI_DEV_FLAGS_NO_BUS_RESET.

Fixes: 4c207e7121fa ("PCI: Mark some NVIDIA GPUs to avoid bus reset")
Link: https://lore.kernel.org/r/2dcebea53a6eb9bd212ec6d8974af2e5e0333ef6.1681129861.git.wuzongyong@linux.alibaba.com
Signed-off-by: Wu Zongyong &lt;wuzongyong@linux.alibaba.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>PCI: microchip: Correct the DED and SEC interrupt bit offsets</title>
<updated>2023-09-13T07:48:21Z</updated>
<author>
<name>Daire McNamara</name>
</author>
<published>2023-07-28T13:13:55Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5183cbfbddcf09ecc20b679b2aff4ccc5fd4f3db'/>
<id>urn:sha1:5183cbfbddcf09ecc20b679b2aff4ccc5fd4f3db</id>
<content type='text'>
[ Upstream commit 6d473a5a26136edf55c435a1c433e52910e03926 ]

The SEC and DED interrupt bits are laid out the wrong way round so the SEC
interrupt handler attempts to mask, unmask, and clear the DED interrupt
and vice versa. Correct the bit offsets so that each interrupt handler
operates properly.

Link: https://lore.kernel.org/r/20230728131401.1615724-2-daire.mcnamara@microchip.com
Fixes: 6f15a9c9f941 ("PCI: microchip: Add Microchip PolarFire PCIe controller driver")
Signed-off-by: Daire McNamara &lt;daire.mcnamara@microchip.com&gt;
Signed-off-by: Lorenzo Pieralisi &lt;lpieralisi@kernel.org&gt;
Reviewed-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
