kernel.git/drivers/pci, branch linux-5.19.y

PCI: Sanitise firmware BAR assignments behind a PCI-PCI bridge

2022-10-24T07:56:49Z

commit 0e32818397426a688f598f35d3bc762eca6d7592 upstream. When pci_assign_resource() is unable to assign resources to a BAR, it uses pci_revert_fw_address() to fall back to a firmware assignment (if any). Previously pci_revert_fw_address() assumed all addresses could reach the device, but this is not true if the device is below a bridge that only forwards addresses within its windows. This problem was observed on a Tyan Tomcat IV S1564D system where the BIOS did not assign valid addresses to several bridges and USB devices: pci 0000:00:11.0: PCI-to-PCIe bridge to [bus 01-ff] pci 0000:00:11.0: bridge window [io 0xe000-0xefff] pci 0000:01:00.0: PCIe Upstream Port to [bus 02-ff] pci 0000:01:00.0: bridge window [io 0x0000-0x0fff] # unreachable pci 0000:02:02.0: PCIe Downstream Port to [bus 05-ff] pci 0000:02:02.0: bridge window [io 0x0000-0x0fff] # unreachable pci 0000:05:00.0: PCIe-to-PCI bridge to [bus 06-ff] pci 0000:05:00.0: bridge window [io 0x0000-0x0fff] # unreachable pci 0000:06:08.0: USB UHCI 1.1 pci 0000:06:08.0: BAR 4: [io 0xfce0-0xfcff] # unreachable pci 0000:06:08.1: USB UHCI 1.1 pci 0000:06:08.1: BAR 4: [io 0xfce0-0xfcff] # unreachable pci 0000:06:08.0: can't claim BAR 4 [io 0xfce0-0xfcff]: no compatible bridge window pci 0000:06:08.1: can't claim BAR 4 [io 0xfce0-0xfcff]: no compatible bridge window During the first pass of assigning unassigned resources, there was not enough I/O space available, so we couldn't assign the 06:08.0 BAR and reverted to the firmware assignment (still unreachable). Reverting the 06:08.1 assignment failed because it conflicted with 06:08.0: pci 0000:00:11.0: bridge window [io 0xe000-0xefff] pci 0000:01:00.0: no space for bridge window [io size 0x2000] pci 0000:02:02.0: no space for bridge window [io size 0x1000] pci 0000:05:00.0: no space for bridge window [io size 0x1000] pci 0000:06:08.0: BAR 4: no space for [io size 0x0020] pci 0000:06:08.0: BAR 4: trying firmware assignment [io 0xfce0-0xfcff] pci 0000:06:08.1: BAR 4: no space for [io size 0x0020] pci 0000:06:08.1: BAR 4: trying firmware assignment [io 0xfce0-0xfcff] pci 0000:06:08.1: BAR 4: [io 0xfce0-0xfcff] conflicts with 0000:06:08.0 [io 0xfce0-0xfcff] A subsequent pass assigned valid bridge windows and a valid 06:08.1 BAR, but left the 06:08.0 BAR alone, so the UHCI device was still unusable: pci 0000:00:11.0: bridge window [io 0xe000-0xefff] released pci 0000:00:11.0: bridge window [io 0x1000-0x2fff] # reassigned pci 0000:01:00.0: bridge window [io 0x1000-0x2fff] # reassigned pci 0000:02:02.0: bridge window [io 0x2000-0x2fff] # reassigned pci 0000:05:00.0: bridge window [io 0x2000-0x2fff] # reassigned pci 0000:06:08.0: BAR 4: assigned [io 0xfce0-0xfcff] # left alone pci 0000:06:08.1: BAR 4: assigned [io 0x2000-0x201f] ... uhci_hcd 0000:06:08.0: host system error, PCI problems? uhci_hcd 0000:06:08.0: host controller process error, something bad happened! uhci_hcd 0000:06:08.0: host controller halted, very bad! uhci_hcd 0000:06:08.0: HCRESET not completed yet! uhci_hcd 0000:06:08.0: HC died; cleaning up If the address assigned by firmware is not reachable because it's not within upstream bridge windows, fail instead of assigning the unusable address from firmware. [bhelgaas: commit log, use pci_upstream_bridge()] Link: https://bugzilla.kernel.org/show_bug.cgi?id=16263 Link: https://lore.kernel.org/r/alpine.DEB.2.21.2203012338460.46819@angie.orcam.me.uk Link: https://lore.kernel.org/r/alpine.DEB.2.21.2209211921250.29493@angie.orcam.me.uk Fixes: 58c84eda0756 ("PCI: fall back to original BIOS BAR addresses") Signed-off-by: Maciej W. Rozycki Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org # v2.6.35+ Signed-off-by: Greg Kroah-Hartman

Revert "PCI/portdrv: Don't disable AER reporting in get_port_device_capability()"

2022-09-05T08:31:27Z

This reverts commit 65e393fddc5379b2c41ca7e73cd4bb9572c4d90e which is commit 8795e182b02dc87e343c79e73af6b8b7f9c5e635 upstream. It is reported to cause problems, so drop it from the stable trees for now until it gets sorted out. Link: https://lore.kernel.org/r/47b775c5-57fa-5edf-b59e-8a9041ffbee7@candelatech.com Reported-by: Ben Greear Cc: Stefan Roese Cc: Bjorn Helgaas Cc: Pali Rohár Cc: Rafael J. Wysocki Cc: Bharat Kumar Gogada Cc: Michal Simek Cc: Yao Hongbo Cc: Naveen Naidu Cc: Sasha Levin Signed-off-by: Greg Kroah-Hartman

PCI: aardvark: Fix reporting Slot capabilities on emulated bridge

2022-08-25T09:45:40Z

[ Upstream commit bcdb6fd4f3e9ac1097698c8d8f56b70853b49873 ] Slot capabilities are currently not reported because emulated bridge does not report the PCI_EXP_FLAGS_SLOT flag. Set PCI_EXP_FLAGS_SLOT to let the kernel know that PCI_EXP_SLT* registers are supported. Move setting of PCI_EXP_SLTCTL register from "dynamic" pcie_conf_read function to static buffer as it is only statically filled the PCI_EXP_SLTSTA_PDS flag and dynamic read callback is not needed for this register. Set Presence State Bit to 1 since there is no support for unplugging the card and there is currently no platform able to detect presence of a card - in such a case the bit needs to be set to 1. Finally correctly set Physical Slot Number to 1 since there is only one port and zero value is reserved for ports within the same silicon as Root Port which is not our case for Aardvark HW. Link: https://lore.kernel.org/r/20220524132827.8837-3-kabel@kernel.org Signed-off-by: Pali Rohár Signed-off-by: Marek Behún Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin

PCI: Add ACS quirk for Broadcom BCM5750x NICs

2022-08-25T09:45:39Z

[ Upstream commit afd306a65cedb9589564bdb23a0c368abc4215fd ] The Broadcom BCM5750x NICs may be multi-function devices. They do not advertise ACS capability. Peer-to-peer transactions are not possible between the individual functions, so it is safe to treat them as fully isolated. Add an ACS quirk for these devices so the functions can be in independent IOMMU groups and attached individually to userspace applications using VFIO. Link: https://lore.kernel.org/r/1654796507-28610-1-git-send-email-michael.chan@broadcom.com Signed-off-by: Pavan Chebbi Signed-off-by: Michael Chan Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin

PCI: qcom: Power on PHY before IPQ8074 DBI register accesses

2022-08-17T13:16:08Z

[ Upstream commit a0e43bb9973b06ce5c666f0901e104e2037c1b34 ] Currently the Gen2 port in IPQ8074 will cause the system to hang as it accesses DBI registers in qcom_pcie_init_2_3_3(), and those are only accesible after phy_power_on(). Move the DBI read/writes to a new qcom_pcie_post_init_2_3_3(), which is executed after phy_power_on(). Link: https://lore.kernel.org/r/20220623155004.688090-1-robimarko@gmail.com Fixes: a0fd361db8e5 ("PCI: dwc: Move "dbi", "dbi2", and "addr_space" resource setup into common code") Signed-off-by: Robert Marko Signed-off-by: Bjorn Helgaas Reviewed-by: Dmitry Baryshkov Cc: stable@vger.kernel.org # v5.11+ Signed-off-by: Sasha Levin

PCI/AER: Iterate over error counters instead of error strings

2022-08-17T13:16:08Z

[ Upstream commit 5e6ae050955b566484f3cc6a66e3925eae87a0ed ] Previously we iterated over AER stat *names*, e.g., aer_correctable_error_string[32], but the actual stat *counters* may not be that large, e.g., pdev->aer_stats->dev_cor_errs[16], which means that we printed junk in the sysfs stats files. Iterate over the stat counter arrays instead of the names to avoid this junk. Also, added a build time check to make sure all counters have entries in strings array. Fixes: 0678e3109a3c ("PCI/AER: Simplify __aer_print_error()") Link: https://lore.kernel.org/r/20220509181441.31884-1-mkhalfella@purestorage.com Reported-by: Meeta Saggi Signed-off-by: Mohamed Khalfella Signed-off-by: Bjorn Helgaas Reviewed-by: Meeta Saggi Reviewed-by: Eric Badger Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin

PCI: tegra194: Fix link up retry sequence

2022-08-17T13:15:38Z

[ Upstream commit e05fd6ae77c3e2cc0dba283005d24b6d56d2b1fa ] Add the missing DLF capability offset while clearing DL_FEATURE_EXCHANGE_EN bit during link up retry. Link: https://lore.kernel.org/r/20220721142052.25971-15-vidyas@nvidia.com Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support") Signed-off-by: Vidya Sagar Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin

PCI: tegra194: Fix Root Port interrupt handling

2022-08-17T13:15:37Z

[ Upstream commit 6646e99bcec627e866bc84365af37942c72b4b76 ] As part of Root Port interrupt handling, level-0 register is read first and based on the bits set in that, corresponding level-1 registers are read for further interrupt processing. Since both these values are currently read into the same 'val' variable, checking level-0 bits the second time around is happening on the 'val' variable value of level-1 register contents instead of freshly reading the level-0 value again. Fix by using different variables to store level-0 and level-1 registers contents. Link: https://lore.kernel.org/r/20220721142052.25971-11-vidyas@nvidia.com Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support") Signed-off-by: Vidya Sagar Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin

PCI: qcom: Set up rev 2.1.0 PARF_PHY before enabling clocks

2022-08-17T13:15:32Z

[ Upstream commit 38f897ae3d44900f627cad708a15db498ce2ca31 ] We currently enable clocks BEFORE we write to PARF_PHY_CTRL reg to enable clocks and resets. This causes the driver to never set to a ready state with the error 'Phy link never came up'. This is caused by the PHY clock getting enabled before setting the required bits in the PARF regs. A workaround for this was set but with this new discovery we can drop the workaround and use a proper solution to the problem by just enabling the clock only AFTER the PARF_PHY_CTRL bit is set. This correctly sets up the PCIe link and makes it usable even when a bootloader leaves the PCIe link in an undefined state. Fixes: 82a823833f4e ("PCI: qcom: Add Qualcomm PCIe controller driver") Link: https://lore.kernel.org/r/20220708222743.27019-1-ansuelsmth@gmail.com Signed-off-by: Christian Marangi Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin

PCI/portdrv: Don't disable AER reporting in get_port_device_capability()

2022-08-17T13:15:31Z

[ Upstream commit 8795e182b02dc87e343c79e73af6b8b7f9c5e635 ] AER reporting is currently disabled in the DevCtl registers of all non Root Port PCIe devices on systems using pcie_ports_native || host->native_aer, disabling AER completely in such systems. This is because 2bd50dd800b5 ("PCI: PCIe: Disable PCIe port services during port initialization"), added a call to pci_disable_pcie_error_reporting() *after* the AER setup was completed for the PCIe device tree. Here a longer analysis about the current status of AER enabling / disabling upon bootup provided by Bjorn: pcie_portdrv_probe pcie_port_device_register get_port_device_capability pci_disable_pcie_error_reporting clear CERE NFERE FERE URRE # <-- disable for RP USP DSP pcie_device_init device_register # new AER service device aer_probe aer_enable_rootport # RP only set_downstream_devices_error_reporting set_device_error_reporting # self (RP) if (RP || USP || DSP) pci_enable_pcie_error_reporting set CERE NFERE FERE URRE # <-- enable for RP pci_walk_bus set_device_error_reporting if (RP || USP || DSP) pci_enable_pcie_error_reporting set CERE NFERE FERE URRE # <-- enable for USP DSP In a typical Root Port -> Endpoint hierarchy, the above: - Disables Error Reporting for the Root Port, - Enables Error Reporting for the Root Port, - Does NOT enable Error Reporting for the Endpoint because it is not a Root Port or Switch Port. In a deeper Root Port -> Upstream Switch Port -> Downstream Switch Port -> Endpoint hierarchy: - Disables Error Reporting for the Root Port, - Enables Error Reporting for the Root Port, - Enables Error Reporting for both Switch Ports, - Does NOT enable Error Reporting for the Endpoint because it is not a Root Port or Switch Port, - Disables Error Reporting for the Switch Ports when pcie_portdrv_probe() claims them. AER does not re-enable it because these are not Root Ports. Remove this call to pci_disable_pcie_error_reporting() from get_port_device_capability(), leaving the already enabled AER configuration intact. With this change, AER is enabled in the Root Port and the PCIe switch upstream and downstream ports. Only the PCIe Endpoints don't have AER enabled yet. A follow-up patch will take care of this Endpoint enabling. Fixes: 2bd50dd800b5 ("PCI: PCIe: Disable PCIe port services during port initialization") Link: https://lore.kernel.org/r/20220125071820.2247260-3-sr@denx.de Signed-off-by: Stefan Roese Signed-off-by: Bjorn Helgaas Reviewed-by: Pali Rohár Cc: Rafael J. Wysocki Cc: Bharat Kumar Gogada Cc: Michal Simek Cc: Yao Hongbo Cc: Naveen Naidu Signed-off-by: Sasha Levin