linux-stable.git/drivers/pci, branch v5.17.2

PCI: Avoid broken MSI on SB600 USB devices

2022-04-08T11:58:22+00:00

[ Upstream commit 63cd736f449445edcd7f0bcc7d84453e9beec0aa ]

Some ATI SB600 USB adapters advertise MSI, but if INTx is disabled by
setting PCI_COMMAND_INTX_DISABLE, MSI doesn't work either.  The PCI/PCIe
specs do not require software to set PCI_COMMAND_INTX_DISABLE when enabling
MSI, but Linux has done that for many years.

Mick reported that 306c54d0edb6 ("usb: hcd: Try MSI interrupts on PCI
devices") broke these devices.  Prior to 306c54d0edb6, they used INTx.
Starting with 306c54d0edb6, they use MSI, and and the fact that Linux sets
PCI_COMMAND_INTX_DISABLE means both INTx and MSI are disabled on these
devices.

Avoid this SB600 defect by disabling MSI so we use INTx as before.

Fixes: 306c54d0edb6 ("usb: hcd: Try MSI interrupts on PCI devices")
Link: https://lore.kernel.org/r/20220321183446.1108325-1-helgaas@kernel.org
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215690
Link: https://lore.kernel.org/all/PxIByDyBRcsbpcmVhGSNDFAoUcMmb78ctXCkw6fbpx25TGlCHvA6SJjjFkNr1FfQZMntYPTNyvEnblxzAZ8a6jP9ddLpKeCN6Chi_2FuexU=@protonmail.com/
Link: https://lore.kernel.org/r/20220314101448.90074-1-andriy.shevchenko@linux.intel.com
BugLink: https://lore.kernel.org/all/20200702143045.23429-1-andriy.shevchenko@linux.intel.com/
Reported-by: Mick Lorain 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Sasha Levin

PCI: imx6: Assert i.MX8MM CLKREQ# even if no device present

2022-04-08T11:58:20+00:00

[ Upstream commit 45514f78c65cc9a09437f20e180625f94f769863 ]

The CLKREQ# signal is an open drain, active low signal that is driven
low by the remote Endpoint device. But it might not be driven low if no
Endpoint device is connected.

On i.MX8MM PCIe, phy_init() may fail and system boot may hang if no
Endpoint is connected to assert CLKREQ#.

Handle this as on i.MX8MQ, where we explicitly assert CLKREQ# so the
PHY can be initialized.

Link: https://lore.kernel.org/r/1645672013-8949-1-git-send-email-hongxing.zhu@nxp.com
Fixes: 178e244cb6e2 ("PCI: imx: Add the imx8mm pcie support")
Signed-off-by: Richard Zhu 
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Lucas Stach 
Signed-off-by: Sasha Levin

PCI: imx6: Invoke the PHY exit function after PHY power off

2022-04-08T11:58:20+00:00

[ Upstream commit deaf7a2c2e4b5072a743633bf37c45f34426a093 ]

To balance phy->init_count, invoke the phy_exit() after phy_power_off().

Link: https://lore.kernel.org/r/1646289275-17813-1-git-send-email-hongxing.zhu@nxp.com
Fixes: 178e244cb6e2 ("PCI: imx: Add the imx8mm pcie support")
Signed-off-by: Richard Zhu 
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Lucas Stach 
Signed-off-by: Sasha Levin

PCI: Reduce warnings on possible RW1C corruption

2022-04-08T11:58:15+00:00

[ Upstream commit 92c45b63ce22c8898aa41806e8d6692bcd577510 ]

For hardware that only supports 32-bit writes to PCI there is the
possibility of clearing RW1C (write-one-to-clear) bits. A rate-limited
messages was introduced by fb2659230120, but rate-limiting is not the best
choice here. Some devices may not show the warnings they should if another
device has just produced a bunch of warnings. Also, the number of messages
can be a nuisance on devices which are otherwise working fine.

Change the ratelimit to a single warning per bus. This ensures no bus is
'starved' of emitting a warning and also that there isn't a continuous
stream of warnings. It would be preferable to have a warning per device,
but the pci_dev structure is not available here, and a lookup from devfn
would be far too slow.

Suggested-by: Bjorn Helgaas 
Fixes: fb2659230120 ("PCI: Warn on possible RW1C corruption for sub-32 bit config writes")
Link: https://lore.kernel.org/r/20200806041455.11070-1-mark.tomlinson@alliedtelesis.co.nz
Signed-off-by: Mark Tomlinson 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Florian Fainelli 
Reviewed-by: Rob Herring 
Acked-by: Scott Branden 
Signed-off-by: Sasha Levin

PCI: aardvark: Fix reading PCI_EXP_RTSTA_PME bit on emulated bridge

2022-04-08T11:58:04+00:00

[ Upstream commit 735f5ae49e1b44742cc63ca9b5c1ffde3e94ba91 ]

The emulated bridge returns incorrect value for PCI_EXP_RTSTA register
during readout in advk_pci_bridge_emul_pcie_conf_read() function: the
correct bit is BIT(16), but we are setting BIT(23), because the code
does
  *value = (isr0 & PCIE_MSG_PM_PME_MASK) << 16
where
  PCIE_MSG_PM_PME_MASK
is
  BIT(7).

The code should probably have been something like
  *value = (!!(isr0 & PCIE_MSG_PM_PME_MASK)) << 16,
but we are better of using an if() and using the proper macro for this
bit.

Link: https://lore.kernel.org/r/20220110015018.26359-15-kabel@kernel.org
Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config space")
Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Sasha Levin

PCI: aardvark: Fix reading MSI interrupt number

2022-04-08T11:58:04+00:00

[ Upstream commit 805dfc18dd3d4dd97a987d4406593b5a225b1253 ]

In advk_pcie_handle_msi() it is expected that when bit i in the W1C
register PCIE_MSI_STATUS_REG is cleared, the PCIE_MSI_PAYLOAD_REG is
updated to contain the MSI number corresponding to index i.

Experiments show that this is not so, and instead PCIE_MSI_PAYLOAD_REG
always contains the number of the last received MSI, overall.

Do not read PCIE_MSI_PAYLOAD_REG register for determining MSI interrupt
number. Since Aardvark already forbids more than 32 interrupts and uses
own allocated hwirq numbers, the msi_idx already corresponds to the
received MSI number.

Link: https://lore.kernel.org/r/20220110015018.26359-3-kabel@kernel.org
Fixes: 8c39d710363c ("PCI: aardvark: Add Aardvark PCI host controller driver")
Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Sasha Levin

PCI: xgene: Revert "PCI: xgene: Fix IB window setup"

2022-04-08T11:57:31+00:00

commit 825da4e9cec68713fbb02dc6f71fe1bf65fe8050 upstream.

Commit c7a75d07827a ("PCI: xgene: Fix IB window setup") tried to
fix the damages that 6dce5aa59e0b ("PCI: xgene: Use inbound resources
for setup") caused, but actually didn't improve anything for some
plarforms (at least Mustang and m400 are still broken).

Given that 6dce5aa59e0b has been reverted, revert this patch as well,
restoring the PCIe support on XGene to its pre-5.5, working state.

Link: https://lore.kernel.org/r/YjN8pT5e6/8cRohQ@xps13.dannf
Link: https://lore.kernel.org/r/20220321104843.949645-3-maz@kernel.org
Fixes: c7a75d07827a ("PCI: xgene: Fix IB window setup")
Signed-off-by: Marc Zyngier 
Signed-off-by: Lorenzo Pieralisi 
Cc: stable@vger.kernel.org
Cc: Rob Herring 
Cc: Toan Le 
Cc: Lorenzo Pieralisi 
Cc: Krzysztof Wilczyński 
Cc: Bjorn Helgaas 
Cc: Stéphane Graber 
Cc: dann frazier 
Signed-off-by: Greg Kroah-Hartman

PCI: xgene: Revert "PCI: xgene: Use inbound resources for setup"

2022-04-08T11:57:31+00:00

commit 1874b6d7ab1bdc900e8398026350313ac29caddb upstream.

Commit 6dce5aa59e0b ("PCI: xgene: Use inbound resources for setup")
killed PCIe on my XGene-1 box (a Mustang board). The machine itself
is still alive, but half of its storage (over NVMe) is gone, and the
NVMe driver just times out.

Note that this machine boots with a device tree provided by the
UEFI firmware (2016 vintage), which could well be non conformant
with the spec, hence the breakage.

With the patch reverted, the box boots 5.17-rc8 with flying colors.

Link: https://lore.kernel.org/all/Yf2wTLjmcRj+AbDv@xps13.dannf
Link: https://lore.kernel.org/r/20220321104843.949645-2-maz@kernel.org
Fixes: 6dce5aa59e0b ("PCI: xgene: Use inbound resources for setup")
Signed-off-by: Marc Zyngier 
Signed-off-by: Lorenzo Pieralisi 
Cc: stable@vger.kernel.org
Cc: Rob Herring 
Cc: Toan Le 
Cc: Lorenzo Pieralisi 
Cc: Krzysztof Wilczyński 
Cc: Bjorn Helgaas 
Cc: Stéphane Graber 
Cc: dann frazier 
Signed-off-by: Greg Kroah-Hartman

PCI: pciehp: Clear cmd_busy bit in polling mode

2022-04-08T11:57:31+00:00

commit 92912b175178c7e895f5e5e9f1e30ac30319162b upstream.

Writes to a Downstream Port's Slot Control register are PCIe hotplug
"commands."  If the Port supports Command Completed events, software must
wait for a command to complete before writing to Slot Control again.

pcie_do_write_cmd() sets ctrl->cmd_busy when it writes to Slot Control.  If
software notification is enabled, i.e., PCI_EXP_SLTCTL_HPIE and
PCI_EXP_SLTCTL_CCIE are set, ctrl->cmd_busy is cleared by pciehp_isr().

But when software notification is disabled, as it is when pcie_init()
powers off an empty slot, pcie_wait_cmd() uses pcie_poll_cmd() to poll for
command completion, and it neglects to clear ctrl->cmd_busy, which leads to
spurious timeouts:

  pcieport 0000:00:03.0: pciehp: Timeout on hotplug command 0x01c0 (issued 2264 msec ago)
  pcieport 0000:00:03.0: pciehp: Timeout on hotplug command 0x05c0 (issued 2288 msec ago)

Clear ctrl->cmd_busy in pcie_poll_cmd() when it detects a Command Completed
event (PCI_EXP_SLTSTA_CC).

[bhelgaas: commit log]
Fixes: a5dd4b4b0570 ("PCI: pciehp: Wait for hotplug command completion where necessary")
Link: https://lore.kernel.org/r/20211111054258.7309-1-zhangliguang@linux.alibaba.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215143
Link: https://lore.kernel.org/r/20211126173309.GA12255@wunner.de
Signed-off-by: Liguang Zhang 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Lukas Wunner 
Cc: stable@vger.kernel.org	# v4.19+
Signed-off-by: Greg Kroah-Hartman

PCI: imx6: Allow to probe when dw_pcie_wait_for_link() fails

2022-04-08T11:57:31+00:00

commit f81f095e87715e198471f4653952fe5e3f824874 upstream.

The intention of commit 886a9c134755 ("PCI: dwc: Move link handling into
common code") was to standardize the behavior of link down as explained
in its commit log:

"The behavior for a link down was inconsistent as some drivers would fail
probe in that case while others succeed. Let's standardize this to
succeed as there are usecases where devices (and the link) appear later
even without hotplug. For example, a reconfigured FPGA device."

The pci-imx6 still fails to probe when the link is not present, which
causes the following warning:

imx6q-pcie 8ffc000.pcie: Phy link never came up
imx6q-pcie: probe of 8ffc000.pcie failed with error -110
------------[ cut here ]------------
WARNING: CPU: 0 PID: 30 at drivers/regulator/core.c:2257 _regulator_put.part.0+0x1b8/0x1dc
Modules linked in:
CPU: 0 PID: 30 Comm: kworker/u2:2 Not tainted 5.15.0-next-20211103 #1
Hardware name: Freescale i.MX6 SoloX (Device Tree)
Workqueue: events_unbound async_run_entry_fn
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack_lvl+0x58/0x70)
[] (dump_stack_lvl) from [] (__warn+0xd4/0x154)
[] (__warn) from [] (warn_slowpath_fmt+0x74/0xa8)
[] (warn_slowpath_fmt) from [] (_regulator_put.part.0+0x1b8/0x1dc)
[] (_regulator_put.part.0) from [] (regulator_put+0x2c/0x3c)
[] (regulator_put) from [] (release_nodes+0x50/0x178)

Fix this problem by ignoring the dw_pcie_wait_for_link() error like
it is done on the other dwc drivers.

Tested on imx6sx-sdb and imx6q-sabresd boards.

Link: https://lore.kernel.org/r/20220106103645.2790803-1-festevam@gmail.com
Fixes: 886a9c134755 ("PCI: dwc: Move link handling into common code")
Signed-off-by: Fabio Estevam 
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Rob Herring 
Reviewed-by: Richard Zhu 
Cc: 
Signed-off-by: Greg Kroah-Hartman