<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/pci/controller/dwc, branch v6.1.87</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.87</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.87'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2024-04-03T13:19:34+00:00</updated>
<entry>
<title>PCI: dwc: endpoint: Fix advertised resizable BAR size</title>
<updated>2024-04-03T13:19:34+00:00</updated>
<author>
<name>Niklas Cassel</name>
<email>cassel@kernel.org</email>
</author>
<published>2024-03-07T11:15:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3d863cf207974343457c45b5c2d2d3baabd83e26'/>
<id>urn:sha1:3d863cf207974343457c45b5c2d2d3baabd83e26</id>
<content type='text'>
[ Upstream commit 72e34b8593e08a0ee759b7a038e0b178418ea6f8 ]

The commit message in commit fc9a77040b04 ("PCI: designware-ep: Configure
Resizable BAR cap to advertise the smallest size") claims that it modifies
the Resizable BAR capability to only advertise support for 1 MB size BARs.

However, the commit writes all zeroes to PCI_REBAR_CAP (the register which
contains the possible BAR sizes that a BAR be resized to).

According to the spec, it is illegal to not have a bit set in
PCI_REBAR_CAP, and 1 MB is the smallest size allowed.

Set bit 4 in PCI_REBAR_CAP, so that we actually advertise support for a
1 MB BAR size.

Before:
        Capabilities: [2e8 v1] Physical Resizable BAR
                BAR 0: current size: 1MB
                BAR 1: current size: 1MB
                BAR 2: current size: 1MB
                BAR 3: current size: 1MB
                BAR 4: current size: 1MB
                BAR 5: current size: 1MB
After:
        Capabilities: [2e8 v1] Physical Resizable BAR
                BAR 0: current size: 1MB, supported: 1MB
                BAR 1: current size: 1MB, supported: 1MB
                BAR 2: current size: 1MB, supported: 1MB
                BAR 3: current size: 1MB, supported: 1MB
                BAR 4: current size: 1MB, supported: 1MB
                BAR 5: current size: 1MB, supported: 1MB

Fixes: fc9a77040b04 ("PCI: designware-ep: Configure Resizable BAR cap to advertise the smallest size")
Link: https://lore.kernel.org/linux-pci/20240307111520.3303774-1-cassel@kernel.org
Signed-off-by: Niklas Cassel &lt;cassel@kernel.org&gt;
Signed-off-by: Krzysztof Wilczyński &lt;kwilczynski@kernel.org&gt;
Reviewed-by: Manivannan Sadhasivam &lt;manivannan.sadhasivam@linaro.org&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 5.2
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>PCI: qcom: Enable BDF to SID translation properly</title>
<updated>2024-04-03T13:19:34+00:00</updated>
<author>
<name>Manivannan Sadhasivam</name>
<email>manivannan.sadhasivam@linaro.org</email>
</author>
<published>2024-03-07T11:05:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=04f3652bd0fdad4f3486db6de59aa01d23eb01cb'/>
<id>urn:sha1:04f3652bd0fdad4f3486db6de59aa01d23eb01cb</id>
<content type='text'>
[ Upstream commit bf79e33cdd89db498e00a6131e937259de5f2705 ]

Qcom SoCs making use of ARM SMMU require BDF to SID translation table in
the driver to properly map the SID for the PCIe devices based on their BDF
identifier. This is currently achieved with the help of
qcom_pcie_config_sid_1_9_0() function for SoCs supporting the 1_9_0 config.

But With newer Qcom SoCs starting from SM8450, BDF to SID translation is
set to bypass mode by default in hardware. Due to this, the translation
table that is set in the qcom_pcie_config_sid_1_9_0() is essentially
unused and the default SID is used for all endpoints in SoCs starting from
SM8450.

This is a security concern and also warrants swapping the DeviceID in DT
while using the GIC ITS to handle MSIs from endpoints. The swapping is
currently done like below in DT when using GIC ITS:

      /*
	* MSIs for BDF (1:0.0) only works with Device ID 0x5980.
	* Hence, the IDs are swapped.
	*/
      msi-map = &lt;0x0 &amp;gic_its 0x5981 0x1&gt;,
		&lt;0x100 &amp;gic_its 0x5980 0x1&gt;;

Here, swapping of the DeviceIDs ensure that the endpoint with BDF (1:0.0)
gets the DeviceID 0x5980 which is associated with the default SID as per
the iommu mapping in DT. So MSIs were delivered with IDs swapped so far.
But this also means the Root Port (0:0.0) won't receive any MSIs (for PME,
AER etc...)

So let's fix these issues by clearing the BDF to SID bypass mode for all
SoCs making use of the 1_9_0 config. This allows the PCIe devices to use
the correct SID, thus avoiding the DeviceID swapping hack in DT and also
achieving the isolation between devices.

Fixes: 4c9398822106 ("PCI: qcom: Add support for configuring BDF to SID mapping for SM8250")
Link: https://lore.kernel.org/linux-pci/20240307-pci-bdf-sid-fix-v1-1-9423a7e2d63c@linaro.org
Signed-off-by: Manivannan Sadhasivam &lt;manivannan.sadhasivam@linaro.org&gt;
Signed-off-by: Krzysztof Wilczyński &lt;kwilczynski@kernel.org&gt;
Cc: stable@vger.kernel.org # 5.11
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>PCI: qcom: Rename qcom_pcie_config_sid_sm8250() to reflect IP version</title>
<updated>2024-04-03T13:19:34+00:00</updated>
<author>
<name>Manivannan Sadhasivam</name>
<email>manivannan.sadhasivam@linaro.org</email>
</author>
<published>2023-03-16T08:11:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a601e7a7fc8e9b80a78339d4d30335b2fde0ba21'/>
<id>urn:sha1:a601e7a7fc8e9b80a78339d4d30335b2fde0ba21</id>
<content type='text'>
[ Upstream commit 1f70939871b260b52e9d1941f1cad740b7295c2c ]

qcom_pcie_config_sid_sm8250() function no longer applies only to SM8250.
So let's rename it to reflect the actual IP version and also move its
definition to keep it sorted as per IP revisions.

Link: https://lore.kernel.org/r/20230316081117.14288-15-manivannan.sadhasivam@linaro.org
Signed-off-by: Manivannan Sadhasivam &lt;manivannan.sadhasivam@linaro.org&gt;
Signed-off-by: Lorenzo Pieralisi &lt;lpieralisi@kernel.org&gt;
Stable-dep-of: bf79e33cdd89 ("PCI: qcom: Enable BDF to SID translation properly")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>PCI: layerscape: Add workaround for lost link capabilities during reset</title>
<updated>2024-03-06T14:45:05+00:00</updated>
<author>
<name>Xiaowei Bao</name>
<email>xiaowei.bao@nxp.com</email>
</author>
<published>2023-07-20T13:58:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=507eeaad4d32174640440f225a30112d8cccd374'/>
<id>urn:sha1:507eeaad4d32174640440f225a30112d8cccd374</id>
<content type='text'>
[ Upstream commit 17cf8661ee0f065c08152e611a568dd1fb0285f1 ]

The endpoint controller loses the Maximum Link Width and Supported Link Speed
value from the Link Capabilities Register - initially configured by the Reset
Configuration Word (RCW) - during a link-down or hot reset event.

Address this issue in the endpoint event handler.

Link: https://lore.kernel.org/r/20230720135834.1977616-2-Frank.Li@nxp.com
Fixes: a805770d8a22 ("PCI: layerscape: Add EP mode support")
Signed-off-by: Xiaowei Bao &lt;xiaowei.bao@nxp.com&gt;
Signed-off-by: Hou Zhiqiang &lt;Zhiqiang.Hou@nxp.com&gt;
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;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>PCI: layerscape: Add the endpoint linkup notifier support</title>
<updated>2024-03-06T14:45:05+00:00</updated>
<author>
<name>Frank Li</name>
<email>Frank.Li@nxp.com</email>
</author>
<published>2023-05-15T15:10:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e30f82597bf64ad32f3b9718bb12791bf3926f3d'/>
<id>urn:sha1:e30f82597bf64ad32f3b9718bb12791bf3926f3d</id>
<content type='text'>
[ Upstream commit 061cbfab09fb35898f2907d42f936cf9ae271d93 ]

Layerscape has PME interrupt, which can be used as linkup notifier.  Set
CFG_READY bit of PEX_PF0_CONFIG to enable accesses from root complex when
linkup detected.

Link: https://lore.kernel.org/r/20230515151049.2797105-1-Frank.Li@nxp.com
Signed-off-by: Xiaowei Bao &lt;xiaowei.bao@nxp.com&gt;
Signed-off-by: Frank Li &lt;Frank.Li@nxp.com&gt;
Signed-off-by: Lorenzo Pieralisi &lt;lpieralisi@kernel.org&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Manivannan Sadhasivam &lt;manivannan.sadhasivam@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>PCI: dwc: Fix a 64bit bug in dw_pcie_ep_raise_msix_irq()</title>
<updated>2024-03-01T12:26:25+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@linaro.org</email>
</author>
<published>2024-01-26T08:40:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6967ddd378e9d63f5c59dbace8b2cf963d6d6a0d'/>
<id>urn:sha1:6967ddd378e9d63f5c59dbace8b2cf963d6d6a0d</id>
<content type='text'>
commit b5d1b4b46f856da1473c7ba9a5cdfcb55c9b2478 upstream.

The "msg_addr" variable is u64.  However, the "aligned_offset" is an
unsigned int.  This means that when the code does:

  msg_addr &amp;= ~aligned_offset;

it will unintentionally zero out the high 32 bits.  Use ALIGN_DOWN() to do
the alignment instead.

Fixes: 2217fffcd63f ("PCI: dwc: endpoint: Fix dw_pcie_ep_raise_msix_irq() alignment support")
Link: https://lore.kernel.org/r/af59c7ad-ab93-40f7-ad4a-7ac0b14d37f5@moroto.mountain
Signed-off-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Niklas Cassel &lt;cassel@kernel.org&gt;
Reviewed-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Reviewed-by: Manivannan Sadhasivam &lt;manivannan.sadhasivam@linaro.org&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Niklas Cassel &lt;cassel@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>PCI: keystone: Fix race condition when initializing PHYs</title>
<updated>2024-01-25T23:27:48+00:00</updated>
<author>
<name>Siddharth Vadapalli</name>
<email>s-vadapalli@ti.com</email>
</author>
<published>2023-09-27T04:18:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=94667790e5e316201d4b9a5072af00e14ad492f0'/>
<id>urn:sha1:94667790e5e316201d4b9a5072af00e14ad492f0</id>
<content type='text'>
[ Upstream commit c12ca110c613a81cb0f0099019c839d078cd0f38 ]

The PCI driver invokes the PHY APIs using the ks_pcie_enable_phy()
function. The PHY in this case is the Serdes. It is possible that the
PCI instance is configured for two lane operation across two different
Serdes instances, using one lane of each Serdes.

In such a configuration, if the reference clock for one Serdes is
provided by the other Serdes, it results in a race condition. After the
Serdes providing the reference clock is initialized by the PCI driver by
invoking its PHY APIs, it is not guaranteed that this Serdes remains
powered on long enough for the PHY APIs based initialization of the
dependent Serdes. In such cases, the PLL of the dependent Serdes fails
to lock due to the absence of the reference clock from the former Serdes
which has been powered off by the PM Core.

Fix this by obtaining reference to the PHYs before invoking the PHY
initialization APIs and releasing reference after the initialization is
complete.

Link: https://lore.kernel.org/linux-pci/20230927041845.1222080-1-s-vadapalli@ti.com
Fixes: 49229238ab47 ("PCI: keystone: Cleanup PHY handling")
Signed-off-by: Siddharth Vadapalli &lt;s-vadapalli@ti.com&gt;
Signed-off-by: Krzysztof Wilczyński &lt;kwilczynski@kernel.org&gt;
Acked-by: Ravi Gunasekaran &lt;r-gunasekaran@ti.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>PCI: dwc: endpoint: Fix dw_pcie_ep_raise_msix_irq() alignment support</title>
<updated>2024-01-25T23:27:44+00:00</updated>
<author>
<name>Niklas Cassel</name>
<email>niklas.cassel@wdc.com</email>
</author>
<published>2023-11-28T13:22:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0c883bc9fa299039707de72ad5cc8fb58b73fbeb'/>
<id>urn:sha1:0c883bc9fa299039707de72ad5cc8fb58b73fbeb</id>
<content type='text'>
commit 2217fffcd63f86776c985d42e76daa43a56abdf1 upstream.

Commit 6f5e193bfb55 ("PCI: dwc: Fix dw_pcie_ep_raise_msix_irq() to get
correct MSI-X table address") modified dw_pcie_ep_raise_msix_irq() to
support iATUs which require a specific alignment.

However, this support cannot have been properly tested.

The whole point is for the iATU to map an address that is aligned,
using dw_pcie_ep_map_addr(), and then let the writel() write to
ep-&gt;msi_mem + aligned_offset.

Thus, modify the address that is mapped such that it is aligned.
With this change, dw_pcie_ep_raise_msix_irq() matches the logic in
dw_pcie_ep_raise_msi_irq().

Link: https://lore.kernel.org/linux-pci/20231128132231.2221614-1-nks@flawful.org
Fixes: 6f5e193bfb55 ("PCI: dwc: Fix dw_pcie_ep_raise_msix_irq() to get correct MSI-X table address")
Signed-off-by: Niklas Cassel &lt;niklas.cassel@wdc.com&gt;
Signed-off-by: Krzysztof Wilczyński &lt;kwilczynski@kernel.org&gt;
Reviewed-by: Manivannan Sadhasivam &lt;manivannan.sadhasivam@linaro.org&gt;
Cc: stable@vger.kernel.org # 5.7
Cc: Kishon Vijay Abraham I &lt;kishon@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>PCI: qcom-ep: Add dedicated callback for writing to DBI2 registers</title>
<updated>2023-12-08T07:51:18+00:00</updated>
<author>
<name>Manivannan Sadhasivam</name>
<email>manivannan.sadhasivam@linaro.org</email>
</author>
<published>2023-10-25T13:00:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5bc8d96fedcea51313021d779ff977d4f2172902'/>
<id>urn:sha1:5bc8d96fedcea51313021d779ff977d4f2172902</id>
<content type='text'>
[ Upstream commit a07d2497ed657eb2efeb967af47e22f573dcd1d6 ]

The DWC core driver exposes the write_dbi2() callback for writing to the
DBI2 registers in a vendor-specific way.

On the Qcom EP platforms, the DBI_CS2 bit in the ELBI region needs to be
asserted before writing to any DBI2 registers and deasserted once done.

So, let's implement the callback for the Qcom PCIe EP driver so that the
DBI2 writes are correctly handled in the hardware.

Without this callback, the DBI2 register writes like BAR size won't go
through and as a result, the default BAR size is set for all BARs.

[kwilczynski: commit log, renamed function to match the DWC convention]
Fixes: f55fee56a631 ("PCI: qcom-ep: Add Qualcomm PCIe Endpoint controller driver")
Suggested-by: Serge Semin &lt;fancer.lancer@gmail.com&gt;
Link: https://lore.kernel.org/linux-pci/20231025130029.74693-2-manivannan.sadhasivam@linaro.org
Signed-off-by: Manivannan Sadhasivam &lt;manivannan.sadhasivam@linaro.org&gt;
Signed-off-by: Krzysztof Wilczyński &lt;kwilczynski@kernel.org&gt;
Reviewed-by: Serge Semin &lt;fancer.lancer@gmail.com&gt;
Cc: stable@vger.kernel.org # 5.16+
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>PCI: exynos: Don't discard .remove() callback</title>
<updated>2023-11-28T17:07:11+00:00</updated>
<author>
<name>Uwe Kleine-König</name>
<email>u.kleine-koenig@pengutronix.de</email>
</author>
<published>2023-10-01T17:02:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=efd8e6d19c148e285dd4b80afc917a023ebce55b'/>
<id>urn:sha1:efd8e6d19c148e285dd4b80afc917a023ebce55b</id>
<content type='text'>
commit 83a939f0fdc208ff3639dd3d42ac9b3c35607fd2 upstream.

With CONFIG_PCI_EXYNOS=y and exynos_pcie_remove() marked with __exit, the
function is discarded from the driver. In this case a bound device can
still get unbound, e.g via sysfs. Then no cleanup code is run resulting in
resource leaks or worse.

The right thing to do is do always have the remove callback available.
This fixes the following warning by modpost:

  WARNING: modpost: drivers/pci/controller/dwc/pci-exynos: section mismatch in reference: exynos_pcie_driver+0x8 (section: .data) -&gt; exynos_pcie_remove (section: .exit.text)

(with ARCH=x86_64 W=1 allmodconfig).

Fixes: 340cba6092c2 ("pci: Add PCIe driver for Samsung Exynos")
Link: https://lore.kernel.org/r/20231001170254.2506508-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Alim Akhtar &lt;alim.akhtar@samsung.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
