linux-stable.git/drivers/pci/controller, branch v6.7.8

PCI: dwc: Fix a 64bit bug in dw_pcie_ep_raise_msix_irq()

2024-02-23T08:51:52+00:00

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 &= ~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 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Niklas Cassel 
Reviewed-by: Ilpo Järvinen 
Reviewed-by: Manivannan Sadhasivam 
Cc: 
Signed-off-by: Greg Kroah-Hartman

PCI/ASPM: Fix deadlock when enabling ASPM

2024-02-16T18:14:30+00:00

commit 1e560864159d002b453da42bd2c13a1805515a20 upstream.

A last minute revert in 6.7-final introduced a potential deadlock when
enabling ASPM during probe of Qualcomm PCIe controllers as reported by
lockdep:

  ============================================
  WARNING: possible recursive locking detected
  6.7.0 #40 Not tainted
  --------------------------------------------
  kworker/u16:5/90 is trying to acquire lock:
  ffffacfa78ced000 (pci_bus_sem){++++}-{3:3}, at: pcie_aspm_pm_state_change+0x58/0xdc

              but task is already holding lock:
  ffffacfa78ced000 (pci_bus_sem){++++}-{3:3}, at: pci_walk_bus+0x34/0xbc

              other info that might help us debug this:
   Possible unsafe locking scenario:

         CPU0
         ----
    lock(pci_bus_sem);
    lock(pci_bus_sem);

               *** DEADLOCK ***

  Call trace:
   print_deadlock_bug+0x25c/0x348
   __lock_acquire+0x10a4/0x2064
   lock_acquire+0x1e8/0x318
   down_read+0x60/0x184
   pcie_aspm_pm_state_change+0x58/0xdc
   pci_set_full_power_state+0xa8/0x114
   pci_set_power_state+0xc4/0x120
   qcom_pcie_enable_aspm+0x1c/0x3c [pcie_qcom]
   pci_walk_bus+0x64/0xbc
   qcom_pcie_host_post_init_2_7_0+0x28/0x34 [pcie_qcom]

The deadlock can easily be reproduced on machines like the Lenovo ThinkPad
X13s by adding a delay to increase the race window during asynchronous
probe where another thread can take a write lock.

Add a new pci_set_power_state_locked() and associated helper functions that
can be called with the PCI bus semaphore held to avoid taking the read lock
twice.

Link: https://lore.kernel.org/r/ZZu0qx2cmn7IwTyQ@hovoldconsulting.com
Link: https://lore.kernel.org/r/20240130100243.11011-1-johan+linaro@kernel.org
Fixes: f93e71aea6c6 ("Revert "PCI/ASPM: Remove pcie_aspm_pm_state_change()"")
Signed-off-by: Johan Hovold 
Signed-off-by: Bjorn Helgaas 
Cc: 	# 6.7
Signed-off-by: Greg Kroah-Hartman

PCI: mediatek-gen3: Fix translation window size calculation

2024-01-25T23:45:26+00:00

[ Upstream commit 9ccc1318cf4bd90601f221268e42c3374703d681 ]

When using the fls() helper, the translation table should be a power of
two; otherwise, the resulting value will not be correct.

For example, given fls(0x3e00000) - 1 = 25, the PCIe translation window
size will be set to 0x2000000 instead of the expected size 0x3e00000.

Fix the translation window by splitting the MMIO space into multiple tables
if its size is not a power of two.

[kwilczynski: commit log]
Link: https://lore.kernel.org/linux-pci/20231023081423.18559-1-jianjun.wang@mediatek.com
Fixes: d3bf75b579b9 ("PCI: mediatek-gen3: Add MediaTek Gen3 driver for MT8192")
Signed-off-by: Jianjun Wang 
Signed-off-by: Krzysztof Wilczyński 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: AngeloGioacchino Del Regno 
Signed-off-by: Sasha Levin

PCI: keystone: Fix race condition when initializing PHYs

2024-01-25T23:45:25+00:00

[ 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 
Signed-off-by: Krzysztof Wilczyński 
Acked-by: Ravi Gunasekaran 
Signed-off-by: Sasha Levin

PCI: xilinx-xdma: Fix error code in xilinx_pl_dma_pcie_init_irq_domain()

2024-01-25T23:45:25+00:00

[ Upstream commit 2324be17b5e05ac682e7c81fcbfc7b36a9b1becb ]

Currently, if the function irq_domain_add_linear() fails to allocate
a new IRQ domain and returns NULL, we would then still return a success
from the xilinx_pl_dma_pcie_init_irq_domain() function regardless, as
the PTR_ERR(NULL) would return a value of zero.  This is not a desirable
outcome.

Thus, fix the incorrect error code and return the -ENOMEM error code if
the irq_domain_add_linear() fails to allocate a new IRQ domain.

[kwilczynski: commit log]
Link: https://lore.kernel.org/linux-pci/20231030072757.3236546-1-harshit.m.mogalapalli@oracle.com
Fixes: 8d786149d78c ("PCI: xilinx-xdma: Add Xilinx XDMA Root Port driver")
Signed-off-by: Harshit Mogalapalli 
Signed-off-by: Krzysztof Wilczyński 
Signed-off-by: Sasha Levin

PCI: xilinx-xdma: Fix uninitialized symbols in xilinx_pl_dma_pcie_setup_irq()

2024-01-25T23:45:25+00:00

[ Upstream commit 7aa5f8fcd6d95b713a39fe52c296a6892eda7f02 ]

The error paths that follow calls to the devm_request_irq() functions
within the xilinx_pl_dma_pcie_setup_irq() reference an uninitialized
symbol each that also so happens to be incorrect.

Thus, fix this omission and reference the correct variable when invoking
a given dev_err() function following an error.

This problem was found using smatch via the 0-DAY CI Kernel Test service:

  drivers/pci/controller/pcie-xilinx-dma-pl.c:638 xilinx_pl_dma_pcie_setup_irq() error: uninitialized symbol 'irq'.
  drivers/pci/controller/pcie-xilinx-dma-pl.c:645 xilinx_pl_dma_pcie_setup_irq() error: uninitialized symbol 'irq'.

Fixes: 8d786149d78c ("PCI: xilinx-xdma: Add Xilinx XDMA Root Port driver")
Link: https://lore.kernel.org/oe-kbuild/202312120248.5DblxkBp-lkp@intel.com/
Reported-by: kernel test robot 
Reported-by: Dan Carpenter 
Closes: https://lore.kernel.org/r/202312120248.5DblxkBp-lkp@intel.com/
Signed-off-by: Krzysztof Wilczyński 
Signed-off-by: Sasha Levin

PCI: mediatek: Clear interrupt status before dispatching handler

2024-01-25T23:45:17+00:00

commit 4e11c29873a8a296a20f99b3e03095e65ebf897d upstream.

We found a failure when using the iperf tool during WiFi performance
testing, where some MSIs were received while clearing the interrupt
status, and these MSIs cannot be serviced.

The interrupt status can be cleared even if the MSI status remains pending.
As such, given the edge-triggered interrupt type, its status should be
cleared before being dispatched to the handler of the underling device.

[kwilczynski: commit log, code comment wording]
Link: https://lore.kernel.org/linux-pci/20231211094923.31967-1-jianjun.wang@mediatek.com
Fixes: 43e6409db64d ("PCI: mediatek: Add MSI support for MT2712 and MT7622")
Signed-off-by: qizhong cheng 
Signed-off-by: Jianjun Wang 
Signed-off-by: Krzysztof Wilczyński 
[bhelgaas: rewrap comment]
Signed-off-by: Bjorn Helgaas 
Reviewed-by: AngeloGioacchino Del Regno 
Cc:  
Signed-off-by: Greg Kroah-Hartman

PCI: dwc: endpoint: Fix dw_pcie_ep_raise_msix_irq() alignment support

2024-01-25T23:45:16+00:00

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->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 
Signed-off-by: Krzysztof Wilczyński 
Reviewed-by: Manivannan Sadhasivam 
Cc: stable@vger.kernel.org # 5.7
Cc: Kishon Vijay Abraham I 
Signed-off-by: Greg Kroah-Hartman

PCI: qcom: Clean up ASPM comment

2023-12-11T18:08:53+00:00

Break up the newly added ASPM comment so that it fits within the soft 80
character limit and becomes more readable.

Link: https://lore.kernel.org/r/20231128081512.19387-5-johan+linaro@kernel.org
Signed-off-by: Johan Hovold 
Signed-off-by: Bjorn Helgaas

PCI: qcom: Fix potential deadlock when enabling ASPM

2023-12-11T18:08:43+00:00

The qcom_pcie_enable_aspm() helper is called from pci_walk_bus() during
host init to enable ASPM.

Since pci_walk_bus() already holds a pci_bus_sem read lock, use
pci_enable_link_state_locked() to enable link states in order to avoid a
potential deadlock (e.g. in case someone takes a write lock before
reacquiring the read lock).

This issue was reported by lockdep:

  ============================================
  WARNING: possible recursive locking detected
  6.7.0-rc1 #4 Not tainted
  --------------------------------------------
  kworker/u16:6/147 is trying to acquire lock:
  ffffbf3ff9d2cfa0 (pci_bus_sem){++++}-{3:3}, at: pci_enable_link_state+0x74/0x1e8

  but task is already holding lock:
  ffffbf3ff9d2cfa0 (pci_bus_sem){++++}-{3:3}, at: pci_walk_bus+0x34/0xbc

  other info that might help us debug this:
   Possible unsafe locking scenario:

         CPU0
         ----
    lock(pci_bus_sem);
    lock(pci_bus_sem);

   *** DEADLOCK ***

Fixes: 9f4f3dfad8cf ("PCI: qcom: Enable ASPM for platforms supporting 1.9.0 ops")
Link: https://lore.kernel.org/r/20231128081512.19387-4-johan+linaro@kernel.org
Signed-off-by: Johan Hovold 
[bhelgaas: add "potential" in subject since the deadlock has only been
reported by lockdep, include helper name in commit log]
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Manivannan Sadhasivam