aboutsummaryrefslogtreecommitdiff
path: root/drivers/pci/controller
AgeCommit message (Collapse)AuthorFilesLines
2023-06-22PCI: rockchip: Assert PCI Configuration Enable bit after probeRick Wertenbroek1-0/+3
Assert PCI Configuration Enable bit after probe. When this bit is left to 0 in the endpoint mode, the RK3399 PCIe endpoint core will generate configuration request retry status (CRS) messages back to the root complex. Assert this bit after probe to allow the RK3399 PCIe endpoint core to reply to configuration requests from the root complex. This is documented in section 17.5.8.1.2 of the RK3399 TRM. Link: https://lore.kernel.org/r/[email protected] Fixes: cf590b078391 ("PCI: rockchip: Add EP driver for Rockchip PCIe controller") Tested-by: Damien Le Moal <[email protected]> Signed-off-by: Rick Wertenbroek <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Cc: [email protected]
2023-06-22PCI: rockchip: Write PCI Device ID to correct registerRick Wertenbroek2-2/+6
Write PCI Device ID (DID) to the correct register. The Device ID was not updated through the correct register. Device ID was written to a read-only register and therefore did not work. The Device ID is now set through the correct register. This is documented in the RK3399 TRM section 17.6.6.1.1 Link: https://lore.kernel.org/r/[email protected] Fixes: cf590b078391 ("PCI: rockchip: Add EP driver for Rockchip PCIe controller") Tested-by: Damien Le Moal <[email protected]> Signed-off-by: Rick Wertenbroek <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Cc: [email protected]
2023-06-22PCI: rockchip: Remove writes to unused registersRick Wertenbroek1-10/+0
Remove write accesses to registers that are marked "unused" (and therefore read-only) in the technical reference manual (TRM) (see RK3399 TRM 17.6.8.1) Link: https://lore.kernel.org/r/[email protected] Tested-by: Damien Le Moal <[email protected]> Signed-off-by: Rick Wertenbroek <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Damien Le Moal <[email protected]>
2023-06-20PCI: qcom: Do not advertise hotplug capability for IP v2.1.0Manivannan Sadhasivam1-0/+2
SoCs making use of Qcom PCIe controller IP v2.1.0 do not support hotplug functionality. But the hotplug capability bit is set by default in the hardware. This causes the kernel PCI core to register hotplug service for the controller and send hotplug commands to it. But those commands will timeout generating messages as below during boot and suspend/resume. [ 5.782159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2020 msec ago) [ 5.810161] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2048 msec ago) [ 7.838162] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2020 msec ago) [ 7.870159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2052 msec ago) This not only spams the console output but also induces a delay of a couple of seconds. To fix this issue, let's clear the HPC bit in PCI_EXP_SLTCAP register as a part of the post init sequence to not advertise the hotplug capability for the controller. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]>
2023-06-20PCI: qcom: Do not advertise hotplug capability for IP v1.0.0Manivannan Sadhasivam1-0/+2
SoCs making use of Qcom PCIe controller IP v1.0.0 do not support hotplug functionality. But the hotplug capability bit is set by default in the hardware. This causes the kernel PCI core to register hotplug service for the controller and send hotplug commands to it. But those commands will timeout generating messages as below during boot and suspend/resume. [ 5.782159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2020 msec ago) [ 5.810161] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2048 msec ago) [ 7.838162] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2020 msec ago) [ 7.870159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2052 msec ago) This not only spams the console output but also induces a delay of a couple of seconds. To fix this issue, let's clear the HPC bit in PCI_EXP_SLTCAP register as a part of the post init sequence to not advertise the hotplug capability for the controller. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]>
2023-06-20PCI: qcom: Use post init sequence of IP v2.3.2 for v2.4.0Manivannan Sadhasivam1-29/+1
The post init sequence of IP v2.4.0 is same as v2.3.2. So let's reuse the v2.3.2 sequence which now also disables hotplug capability of the controller as it is not at all supported on any SoCs making use of this IP. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]>
2023-06-20PCI: qcom: Do not advertise hotplug capability for IP v2.3.2Manivannan Sadhasivam1-0/+2
SoCs making use of Qcom PCIe controller IP v2.3.2 do not support hotplug functionality. But the hotplug capability bit is set by default in the hardware. This causes the kernel PCI core to register hotplug service for the controller and send hotplug commands to it. But those commands will timeout generating messages as below during boot and suspend/resume. [ 5.782159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2020 msec ago) [ 5.810161] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2048 msec ago) [ 7.838162] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2020 msec ago) [ 7.870159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2052 msec ago) This not only spams the console output but also induces a delay of a couple of seconds. To fix this issue, let's clear the HPC bit in PCI_EXP_SLTCAP register as a part of the post init sequence to not advertise the hotplug capability for the controller. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]>
2023-06-20PCI: qcom: Do not advertise hotplug capability for IPs v2.3.3 and v2.9.0Manivannan Sadhasivam1-1/+0
SoCs making use of Qcom PCIe controller IPs v2.3.3 and v2.9.0 do not support hotplug functionality. But the hotplug capability bit is set by default in the hardware. This causes the kernel PCI core to register hotplug service for the controller and send hotplug commands to it. But those commands will timeout generating messages as below during boot and suspend/resume. [ 5.782159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2020 msec ago) [ 5.810161] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2048 msec ago) [ 7.838162] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2020 msec ago) [ 7.870159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2052 msec ago) This not only spams the console output but also induces a delay of a couple of seconds. To fix this issue, let's not set the HPC bit in PCI_EXP_SLTCAP register as a part of the post init sequence to not advertise the hotplug capability for the controller. Link: https://lore.kernel.org/r/[email protected] Tested-by: Sricharan Ramabadhran <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]>
2023-06-20PCI: qcom: Do not advertise hotplug capability for IPs v2.7.0 and v1.9.0Manivannan Sadhasivam1-0/+23
SoCs making use of Qcom PCIe controller IPs v2.7.0 and v1.9.0 do not support hotplug functionality. But the hotplug capability bit is set by default in the hardware. This causes the kernel PCI core to register hotplug service for the controller and send hotplug commands to it. But those commands will timeout generating messages as below during boot and suspend/resume. [ 5.782159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2020 msec ago) [ 5.810161] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2048 msec ago) [ 7.838162] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2020 msec ago) [ 7.870159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2052 msec ago) This not only spams the console output but also induces a delay of a couple of seconds. To fix this issue, let's clear the HPC bit in PCI_EXP_SLTCAP register as a part of the post init sequence to not advertise the hotplug capability for the controller. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]>
2023-06-20PCI: qcom: Disable write access to read only registers for IP v2.9.0Manivannan Sadhasivam1-0/+3
In the post init sequence of v2.9.0, write access to read only registers are not disabled after updating the registers. Fix it by disabling the access after register update. While at it, let's also add a newline after existing dw_pcie_dbi_ro_wr_en() guard function to align with rest of the driver. Link: https://lore.kernel.org/r/[email protected] Fixes: 0cf7c2efe8ac ("PCI: qcom: Add IPQ60xx support") Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]>
2023-06-20PCI: qcom: Use DWC helpers for modifying the read-only DBI registersManivannan Sadhasivam1-5/+3
DWC core already exposes dw_pcie_dbi_ro_wr_{en/dis} helper APIs for enabling and disabling the write access to read only DBI registers. So let's use them instead of doing it manually. Also, the existing code doesn't disable the write access when it's done. This is also fixed now. Link: https://lore.kernel.org/r/[email protected] Fixes: 5d76117f070d ("PCI: qcom: Add support for IPQ8074 PCIe controller") Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]>
2023-06-20PCI: qcom: Disable write access to read only registers for IP v2.3.3Manivannan Sadhasivam1-0/+2
In the post init sequence of v2.9.0, write access to read only registers are not disabled after updating the registers. Fix it by disabling the access after register update. Link: https://lore.kernel.org/r/[email protected] Fixes: 5d76117f070d ("PCI: qcom: Add support for IPQ8074 PCIe controller") Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Cc: <[email protected]>
2023-06-19PCI: imx6: Save and restore root port MSI control in suspend and resumeRichard Zhu1-0/+23
The imx6 PCI host controller suffers from a HW integration bug whereby the MSI enable bit in the root port MSI capability enables/disables MSIs interrupts for all downstream components in the PCI tree. This requires, as implemented in 75cb8d20c112 ("PCI: imx: Enable MSI from downstream components") that the root port MSI enable bit should be set in order for downstream PCI devices MSIs to function. The MSI enable bit programming might be lost during the suspend and should be re-stored during resume. Save the MSI control during suspend and restore it in resume. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Richard Zhu <[email protected]> [[email protected]: commit log] Signed-off-by: Lorenzo Pieralisi <[email protected]>
2023-06-18PCI: hv: Add a per-bus mutex state_lockDexuan Cui1-3/+26
In the case of fast device addition/removal, it's possible that hv_eject_device_work() can start to run before create_root_hv_pci_bus() starts to run; as a result, the pci_get_domain_bus_and_slot() in hv_eject_device_work() can return a 'pdev' of NULL, and hv_eject_device_work() can remove the 'hpdev', and immediately send a message PCI_EJECTION_COMPLETE to the host, and the host immediately unassigns the PCI device from the guest; meanwhile, create_root_hv_pci_bus() and the PCI device driver can be probing the dead PCI device and reporting timeout errors. Fix the issue by adding a per-bus mutex 'state_lock' and grabbing the mutex before powering on the PCI bus in hv_pci_enter_d0(): when hv_eject_device_work() starts to run, it's able to find the 'pdev' and call pci_stop_and_remove_bus_device(pdev): if the PCI device driver has loaded, the PCI device driver's probe() function is already called in create_root_hv_pci_bus() -> pci_bus_add_devices(), and now hv_eject_device_work() -> pci_stop_and_remove_bus_device() is able to call the PCI device driver's remove() function and remove the device reliably; if the PCI device driver hasn't loaded yet, the function call hv_eject_device_work() -> pci_stop_and_remove_bus_device() is able to remove the PCI device reliably and the PCI device driver's probe() function won't be called; if the PCI device driver's probe() is already running (e.g., systemd-udev is loading the PCI device driver), it must be holding the per-device lock, and after the probe() finishes and releases the lock, hv_eject_device_work() -> pci_stop_and_remove_bus_device() is able to proceed to remove the device reliably. Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs") Signed-off-by: Dexuan Cui <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Acked-by: Lorenzo Pieralisi <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]>
2023-06-18Revert "PCI: hv: Fix a timing issue which causes kdump to fail occasionally"Dexuan Cui1-37/+34
This reverts commit d6af2ed29c7c1c311b96dac989dcb991e90ee195. The statement "the hv_pci_bus_exit() call releases structures of all its child devices" in commit d6af2ed29c7c is not true: in the path hv_pci_probe() -> hv_pci_enter_d0() -> hv_pci_bus_exit(hdev, true): the parameter "keep_devs" is true, so hv_pci_bus_exit() does *not* release the child "struct hv_pci_dev *hpdev" that is created earlier in pci_devices_present_work() -> new_pcichild_device(). The commit d6af2ed29c7c was originally made in July 2020 for RHEL 7.7, where the old version of hv_pci_bus_exit() was used; when the commit was rebased and merged into the upstream, people didn't notice that it's not really necessary. The commit itself doesn't cause any issue, but it makes hv_pci_probe() more complicated. Revert it to facilitate some upcoming changes to hv_pci_probe(). Signed-off-by: Dexuan Cui <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Acked-by: Wei Hu <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]>
2023-06-18PCI: hv: Remove the useless hv_pcichild_state from struct hv_pci_devDexuan Cui1-12/+0
The hpdev->state is never really useful. The only use in hv_pci_eject_device() and hv_eject_device_work() is not really necessary. Signed-off-by: Dexuan Cui <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Acked-by: Lorenzo Pieralisi <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]>
2023-06-18PCI: hv: Fix a race condition in hv_irq_unmask() that can cause panicDexuan Cui1-6/+5
When the host tries to remove a PCI device, the host first sends a PCI_EJECT message to the guest, and the guest is supposed to gracefully remove the PCI device and send a PCI_EJECTION_COMPLETE message to the host; the host then sends a VMBus message CHANNELMSG_RESCIND_CHANNELOFFER to the guest (when the guest receives this message, the device is already unassigned from the guest) and the guest can do some final cleanup work; if the guest fails to respond to the PCI_EJECT message within one minute, the host sends the VMBus message CHANNELMSG_RESCIND_CHANNELOFFER and removes the PCI device forcibly. In the case of fast device addition/removal, it's possible that the PCI device driver is still configuring MSI-X interrupts when the guest receives the PCI_EJECT message; the channel callback calls hv_pci_eject_device(), which sets hpdev->state to hv_pcichild_ejecting, and schedules a work hv_eject_device_work(); if the PCI device driver is calling pci_alloc_irq_vectors() -> ... -> hv_compose_msi_msg(), we can break the while loop in hv_compose_msi_msg() due to the updated hpdev->state, and leave data->chip_data with its default value of NULL; later, when the PCI device driver calls request_irq() -> ... -> hv_irq_unmask(), the guest crashes in hv_arch_irq_unmask() due to data->chip_data being NULL. Fix the issue by not testing hpdev->state in the while loop: when the guest receives PCI_EJECT, the device is still assigned to the guest, and the guest has one minute to finish the device removal gracefully. We don't really need to (and we should not) test hpdev->state in the loop. Fixes: de0aa7b2f97d ("PCI: hv: Fix 2 hang issues in hv_compose_msi_msg()") Signed-off-by: Dexuan Cui <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]>
2023-06-18PCI: hv: Fix a race condition bug in hv_pci_query_relations()Dexuan Cui1-0/+18
Since day 1 of the driver, there has been a race between hv_pci_query_relations() and survey_child_resources(): during fast device hotplug, hv_pci_query_relations() may error out due to device-remove and the stack variable 'comp' is no longer valid; however, pci_devices_present_work() -> survey_child_resources() -> complete() may be running on another CPU and accessing the no-longer-valid 'comp'. Fix the race by flushing the workqueue before we exit from hv_pci_query_relations(). Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs") Signed-off-by: Dexuan Cui <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Acked-by: Lorenzo Pieralisi <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]>
2023-05-29PCI: rcar-host: Remove unused static pcie_base and pcie_devGeert Uytterhoeven1-21/+0
After the L1 link state transition exception handler rework, the static copies of the remapped PCIe controller address and the PCIe device pointer became unused. Remove them. Link: https://lore.kernel.org/r/f29a8c37bd906dfbe23208cc2b089da17e339a75.1684857051.git.geert+renesas@glider.be Fixes: 6e36203bc14ce147 ("PCI: rcar: Use PCI_SET_ERROR_RESPONSE after read which triggered an exception") Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Yoshihiro Shimoda <[email protected]>
2023-05-29PCI: ftpci100: Release the clock resourcesJunyan Ye1-12/+2
Smatch reported: 1. drivers/pci/controller/pci-ftpci100.c:526 faraday_pci_probe() warn: 'clk' from clk_prepare_enable() not released on lines: 442,451,462,478,512,517. 2. drivers/pci/controller/pci-ftpci100.c:526 faraday_pci_probe() warn: 'p->bus_clk' from clk_prepare_enable() not released on lines: 451,462,478,512,517. The clock resource is obtained by devm_clk_get(), and then clk_prepare_enable() makes the clock resource ready for use. After that, clk_disable_unprepare() should be called to release the clock resource when it is no longer needed. However, while doing some error handling in faraday_pci_probe(), clk_disable_unprepare() is not called to release clk and p->bus_clk before returning. These return lines are exactly 442, 451, 462, 478, 512, 517. Fix this warning by replacing devm_clk_get() with devm_clk_get_enabled(), which is equivalent to devm_clk_get() + clk_prepare_enable(). And with devm_clk_get_enabled(), the clock will automatically be disabled, unprepared and freed when the device is unbound from the bus. Link: https://lore.kernel.org/r/[email protected] Fixes: b3c433efb8a3 ("PCI: faraday: Fix wrong pointer passed to PTR_ERR()") Fixes: 2eeb02b28579 ("PCI: faraday: Add clock handling") Fixes: 783a862563f7 ("PCI: faraday: Use pci_parse_request_of_pci_ranges()") Fixes: d3c68e0a7e34 ("PCI: faraday: Add Faraday Technology FTPCI100 PCI Host Bridge driver") Fixes: f1e8bd21e39e ("PCI: faraday: Convert IRQ masking to raw PCI config accessors") Signed-off-by: Junyan Ye <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Dongliang Mu <[email protected]> Reviewed-by: Linus Walleij <[email protected]>
2023-05-26PCI: dwc: Wait for link up only if link is startedAjay Agarwal3-11/+23
In dw_pcie_host_init() regardless of whether the link has been started or not, the code waits for the link to come up. Even in cases where start_link() is not defined the code ends up spinning in a loop for 1 second. Since in some systems dw_pcie_host_init() gets called during probe, this one second loop for each pcie interface instance ends up extending the boot time. Wait for the link up in only if the start_link() is defined. Link: https://lore.kernel.org/r/[email protected] Tested-by: Will McVicker <[email protected]> Signed-off-by: Sajid Dalvi <[email protected]> Signed-off-by: Ajay Agarwal <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]>
2023-05-24dmaengine: dw-edma: Rename dw_edma_core_ops structure to dw_edma_plat_opsCai Huoqing1-1/+1
The dw_edma_core_ops structure contains a set of the operations: device IRQ numbers getter, CPU/PCI address translation. Based on the functions semantics the structure name "dw_edma_plat_ops" looks more descriptive since indeed the operations are platform-specific. The "dw_edma_core_ops" name shall be used for a structure with the IP-core specific set of callbacks in order to abstract out DW eDMA and DW HDMA setups. Such structure will be added in one of the next commit in the framework of the set of changes adding the DW HDMA device support. Anyway the renaming was necessary to distinguish two types of the implementation callbacks: 1. DW eDMA/hDMA IP-core specific operations: device-specific CSR setups in one or another aspect of the DMA-engine initialization. 2. DW eDMA/hDMA platform specific operations: the DMA device environment configs like IRQs, address translation, etc. Signed-off-by: Cai Huoqing <[email protected]> Reviewed-by: Serge Semin <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Tested-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2023-05-16PCI: tegra194: Add interconnect support in Tegra234Sumit Gupta1-16/+35
Add support to request DRAM bandwidth (BW) with Memory Interconnect in Tegra234 SoC. The DRAM BW required for different modes depends on the link speed (Gen-1/2/3/4) and width/lanes (x1/x2/x4/x8). Currently, the DRAM frequency is always set to the maximum available but that results in the highest power consumption. The Memory Interconnect is a software feature which uses Interconnect framework (ICC). It adds the capability for Memory Controller (MC) clients to request bandwidth and therefore scale DRAM frequency dynamically depending on the required link speed so that the DRAM energy consumption can be optimized. Suggested-by: Manikanta Maddireddy <[email protected]> Signed-off-by: Sumit Gupta <[email protected]> Acked-by: Lorenzo Pieralisi <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2023-05-16PCI: tegra194: Fix possible array out of bounds accessSumit Gupta1-2/+11
Add check to fix the possible array out of bounds violation by making speed equal to GEN1_CORE_CLK_FREQ when its value is more than the size of "pcie_gen_freq" array. This array has size of four but possible speed (CLS) values are from "0 to 0xF". So, "speed - 1" values are "-1 to 0xE". Suggested-by: Bjorn Helgaas <[email protected]> Signed-off-by: Sumit Gupta <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]/ Acked-by: Lorenzo Pieralisi <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2023-05-08PCI: vmd: Reset VMD config register between soft rebootsNirmal Patel1-0/+8
VMD driver can disable or enable MSI remapping by changing VMCONFIG_MSI_REMAP register. This register needs to be set to the default value during soft reboots. Drives failed to enumerate when Windows boots after performing a soft reboot from Linux. Windows doesn't support MSI remapping disable feature and stale register value hinders Windows VMD driver initialization process. Adding vmd_shutdown function to make sure to set the VMCONFIG register to the default value. Link: https://lore.kernel.org/r/[email protected] Fixes: ee81ee84f873 ("PCI: vmd: Disable MSI-X remapping when possible") Signed-off-by: Nirmal Patel <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Jon Derrick <[email protected]>
2023-05-08PCI: cadence: Fix Gen2 Link Retraining processSiddharth Vadapalli1-0/+27
The Link Retraining process is initiated to account for the Gen2 defect in the Cadence PCIe controller in J721E SoC. The errata corresponding to this is i2085, documented at: https://www.ti.com/lit/er/sprz455c/sprz455c.pdf The existing workaround implemented for the errata waits for the Data Link initialization to complete and assumes that the link retraining process at the Physical Layer has completed. However, it is possible that the Physical Layer training might be ongoing as indicated by the PCI_EXP_LNKSTA_LT bit in the PCI_EXP_LNKSTA register. Fix the existing workaround, to ensure that the Physical Layer training has also completed, in addition to the Data Link initialization. Link: https://lore.kernel.org/r/[email protected] Fixes: 4740b969aaf5 ("PCI: cadence: Retrain Link to work around Gen2 training defect") Signed-off-by: Siddharth Vadapalli <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Vignesh Raghavendra <[email protected]>
2023-04-27Merge tag 'hyperv-next-signed-20230424' of ↵Linus Torvalds1-105/+175
git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux Pull hyperv updates from Wei Liu: - PCI passthrough for Hyper-V confidential VMs (Michael Kelley) - Hyper-V VTL mode support (Saurabh Sengar) - Move panic report initialization code earlier (Long Li) - Various improvements and bug fixes (Dexuan Cui and Michael Kelley) * tag 'hyperv-next-signed-20230424' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux: (22 commits) PCI: hv: Replace retarget_msi_interrupt_params with hyperv_pcpu_input_arg Drivers: hv: move panic report code from vmbus to hv early init code x86/hyperv: VTL support for Hyper-V Drivers: hv: Kconfig: Add HYPERV_VTL_MODE x86/hyperv: Make hv_get_nmi_reason public x86/hyperv: Add VTL specific structs and hypercalls x86/init: Make get/set_rtc_noop() public x86/hyperv: Exclude lazy TLB mode CPUs from enlightened TLB flushes x86/hyperv: Add callback filter to cpumask_to_vpset() Drivers: hv: vmbus: Remove the per-CPU post_msg_page clocksource: hyper-v: make sure Invariant-TSC is used if it is available PCI: hv: Enable PCI pass-thru devices in Confidential VMs Drivers: hv: Don't remap addresses that are above shared_gpa_boundary hv_netvsc: Remove second mapping of send and recv buffers Drivers: hv: vmbus: Remove second way of mapping ring buffers Drivers: hv: vmbus: Remove second mapping of VMBus monitor pages swiotlb: Remove bounce buffer remapping for Hyper-V Driver: VMBus: Add Devicetree support dt-bindings: bus: Add Hyper-V VMBus Drivers: hv: vmbus: Convert acpi_device to more generic platform_device ...
2023-04-27Merge tag 'pci-v6.4-changes' of ↵Linus Torvalds13-1182/+981
git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci Pull pci updates from Bjorn Helgaas: "Resource management: - Add pci_dev_for_each_resource() and pci_bus_for_each_resource() iterators PCIe native device hotplug: - Fix AB-BA deadlock between reset_lock and device_lock Power management: - Wait longer for devices to become ready after resume (as we do for reset) to accommodate Intel Titan Ridge xHCI devices - Extend D3hot delay for NVIDIA HDA controllers to avoid unrecoverable devices after a bus reset Error handling: - Clear PCIe Device Status after EDR since generic error recovery now only clears it when AER is native ASPM: - Work around Chromebook firmware defect that clobbers Capability list (including ASPM L1 PM Substates Cap) when returning from D3cold to D0 Freescale i.MX6 PCIe controller driver: - Install imprecise external abort handler only when DT indicates PCIe support Freescale Layerscape PCIe controller driver: - Add ls1028a endpoint mode support Qualcomm PCIe controller driver: - Add SM8550 DT binding and driver support - Add SDX55 DT binding and driver support - Use bulk APIs for clocks of IP 1.0.0, 2.3.2, 2.3.3 - Use bulk APIs for reset of IP 2.1.0, 2.3.3, 2.4.0 - Add DT "mhi" register region for supported SoCs - Expose link transition counts via debugfs to help debug low power issues - Support system suspend and resume; reduce interconnect bandwidth and turn off clock and PHY if there are no active devices - Enable async probe by default to reduce boot time Miscellaneous: - Sort controller Kconfig entries by vendor" * tag 'pci-v6.4-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: (56 commits) PCI: xilinx: Drop obsolete dependency on COMPILE_TEST PCI: mobiveil: Sort Kconfig entries by vendor PCI: dwc: Sort Kconfig entries by vendor PCI: Sort controller Kconfig entries by vendor PCI: Use consistent controller Kconfig menu entry language PCI: xilinx-nwl: Add 'Xilinx' to Kconfig prompt PCI: hv: Add 'Microsoft' to Kconfig prompt PCI: meson: Add 'Amlogic' to Kconfig prompt PCI: Use of_property_present() for testing DT property presence PCI/PM: Extend D3hot delay for NVIDIA HDA controllers dt-bindings: PCI: qcom: Document msi-map and msi-map-mask properties PCI: qcom: Add SM8550 PCIe support dt-bindings: PCI: qcom: Add SM8550 compatible PCI: qcom: Add support for SDX55 SoC dt-bindings: PCI: qcom-ep: Fix the unit address used in example dt-bindings: PCI: qcom: Add SDX55 SoC dt-bindings: PCI: qcom: Update maintainers entry PCI: qcom: Enable async probe by default PCI: qcom: Add support for system suspend and resume PCI/PM: Drop pci_bridge_wait_for_secondary_bus() timeout parameter ...
2023-04-21PCI: hv: Replace retarget_msi_interrupt_params with hyperv_pcpu_input_argDexuan Cui1-41/+7
4 commits are involved here: A (2016): commit 0de8ce3ee8e3 ("PCI: hv: Allocate physically contiguous hypercall params buffer") B (2017): commit be66b6736591 ("PCI: hv: Use page allocation for hbus structure") C (2019): commit 877b911a5ba0 ("PCI: hv: Avoid a kmemleak false positive caused by the hbus buffer") D (2018): commit 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments") Patch D introduced the per-CPU hypercall input page "hyperv_pcpu_input_arg" in 2018. With patch D, we no longer need the per-Hyper-V-PCI-bus hypercall input page "hbus->retarget_msi_interrupt_params" that was added in patch A, and the issue addressed by patch B is no longer an issue, and we can also get rid of patch C. The change here is required for PCI device assignment to work for Confidential VMs (CVMs) running without a paravisor, because otherwise we would have to call set_memory_decrypted() for "hbus->retarget_msi_interrupt_params" before calling the hypercall HVCALL_RETARGET_INTERRUPT. Signed-off-by: Dexuan Cui <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Acked-by: Lorenzo Pieralisi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]>
2023-04-20PCI: xilinx: Drop obsolete dependency on COMPILE_TESTJean Delvare1-1/+1
Since commit 0166dc11be91 ("of: make CONFIG_OF user selectable"), it is possible to test-build any driver which depends on OF on any architecture by explicitly selecting OF. Therefore depending on COMPILE_TEST as an alternative is no longer needed. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jean Delvare <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Cc: Lorenzo Pieralisi <[email protected]> Cc: Rob Herring <[email protected]> Cc: "Krzysztof Wilczyński" <[email protected]>
2023-04-20PCI: mobiveil: Sort Kconfig entries by vendorBjorn Helgaas1-8/+9
Sort Kconfig entries by vendor so they appear in alphabetical order in menuconfig. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Helgaas <[email protected]>
2023-04-20PCI: dwc: Sort Kconfig entries by vendorBjorn Helgaas1-203/+203
Sort Kconfig entries by vendor so they appear in alphabetical order in menuconfig. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Helgaas <[email protected]>
2023-04-20PCI: Sort controller Kconfig entries by vendorBjorn Helgaas1-207/+207
Sort Kconfig entries by vendor so they appear in alphabetical order in menuconfig. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Helgaas <[email protected]>
2023-04-20PCI: Use consistent controller Kconfig menu entry languageBjorn Helgaas4-45/+45
Use "PCIe controller" consistently instead of "host bridge", "bus driver", etc. Annotate with "(host mode)" or "(endpoint mode)" as needed. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Helgaas <[email protected]>
2023-04-20PCI: xilinx-nwl: Add 'Xilinx' to Kconfig promptBjorn Helgaas1-1/+1
Add the "Xilinx" vendor name to the CONFIG_PCIE_XILINX_NWL Kconfig prompt so it matches other drivers. Rename from "PCIe Core" to "PCIe controller". Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Michal Simek <[email protected]>
2023-04-20PCI: hv: Add 'Microsoft' to Kconfig promptBjorn Helgaas1-3/+4
Add the "Microsoft" vendor name to the CONFIG_PCI_HYPERV_INTERFACE Kconfig prompt so it matches other PCIe drivers and other Hyper-V prompts. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Wei Liu <[email protected]> Cc: K. Y. Srinivasan <[email protected]> Cc: Haiyang Zhang <[email protected]> Cc: Dexuan Cui <[email protected]>
2023-04-20PCI: meson: Add 'Amlogic' to Kconfig promptBjorn Helgaas1-1/+1
Add the "Amlogic" vendor name to the CONFIG_PCI_MESON Kconfig prompt to match other PCIe drivers. Capitalize "Meson" to match other Meson Kconfig prompts. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Helgaas <[email protected]> Cc: Yue Wang <[email protected]>
2023-04-20Merge branch 'pci/controller/rcar'Bjorn Helgaas2-3/+3
- Rename internal #defines without "CONFIG_" prefix to avoid confusion (Lukas Bulwahn) * pci/controller/rcar: PCI: rcar: Avoid defines prefixed with CONFIG
2023-04-20Merge branch 'pci/controller/qcom'Bjorn Helgaas1-730/+516
- Use correct PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT_V2 register for v2.7.0 (Manivannan Sadhasivam) - Remove "PCIE20_" prefix from register definitions (Manivannan Sadhasivam) - Sort registers and bitfield declarations (Manivannan Sadhasivam) - Convert to GENMASK and FIELD_PREP (Manivannan Sadhasivam) - Use bulk APIs for clocks of IP 1.0.0, 2.3.2, 2.3.3 (Manivannan Sadhasivam) - Use bulk APIs for reset of IP 2.1.0, 2.3.3, 2.4.0 (Manivannan Sadhasivam) - Rename qcom_pcie_config_sid_sm8250() to be non SM8250-specific (Manivannan Sadhasivam) - Add DT "mhi" register region for supported SoCs (Manivannan Sadhasivam) - Expose link transition counts via debugfs to help debug low power issues (Manivannan Sadhasivam) - Support system suspend and resume; reduce interconnect bandwidth and turn off clock and PHY if there are no active devices (Manivannan Sadhasivam) - Enable async probe by default to reduce boot time (Manivannan Sadhasivam) - Add Manivannan Sadhasivam as qcom DT binding maintainer, replacing Stanimir Varbanov (Manivannan Sadhasivam) - Add DT binding and driver support for Qcom SDX55 SoC (Manivannan Sadhasivam) - Add DT binding and driver support for SM8550 SoC (Abel Vesa) - Document msi-map and msi-map-mask DT properties (Manivannan Sadhasivam) * pci/controller/qcom: dt-bindings: PCI: qcom: Document msi-map and msi-map-mask properties PCI: qcom: Add SM8550 PCIe support dt-bindings: PCI: qcom: Add SM8550 compatible PCI: qcom: Add support for SDX55 SoC dt-bindings: PCI: qcom-ep: Fix the unit address used in example dt-bindings: PCI: qcom: Add SDX55 SoC dt-bindings: PCI: qcom: Update maintainers entry PCI: qcom: Enable async probe by default PCI: qcom: Add support for system suspend and resume PCI: qcom: Expose link transition counts via debugfs dt-bindings: PCI: qcom: Add "mhi" register region to supported SoCs PCI: qcom: Rename qcom_pcie_config_sid_sm8250() to reflect IP version PCI: qcom: Use macros for defining total no. of clocks & supplies PCI: qcom: Use bulk reset APIs for handling resets for IP rev 2.4.0 PCI: qcom: Use bulk reset APIs for handling resets for IP rev 2.3.3 PCI: qcom: Use bulk clock APIs for handling clocks for IP rev 2.3.3 PCI: qcom: Use bulk clock APIs for handling clocks for IP rev 2.3.2 PCI: qcom: Use bulk clock APIs for handling clocks for IP rev 1.0.0 PCI: qcom: Use bulk reset APIs for handling resets for IP rev 2.1.0 PCI: qcom: Use lower case for hex PCI: qcom: Add missing macros for register fields PCI: qcom: Use bitfield definitions for register fields PCI: qcom: Sort and group registers and bitfield definitions PCI: qcom: Remove PCIE20_ prefix from register definitions PCI: qcom: Fix the incorrect register usage in v2.7.0 config
2023-04-20Merge branch 'pci/controller/mt7621'Bjorn Helgaas1-2/+2
- Log empty slots with dev_info(), not dev_err() (Sergio Paracuellos) * pci/controller/mt7621: PCI: mt7621: Use dev_info() to log PCIe card detection
2023-04-20Merge branch 'pci/controller/layerscape'Bjorn Helgaas1-0/+1
- Add ls1028a endpoint mode support (Xiaowei Bao) * pci/controller/layerscape: PCI: layerscape: Add EP mode support for ls1028a
2023-04-20Merge branch 'pci/controller/kirin'Bjorn Helgaas1-0/+1
- Select CONFIG_REGMAP_MMIO so kirin driver links correctly (Josh Triplett) * pci/controller/kirin: PCI: kirin: Select REGMAP_MMIO
2023-04-20Merge branch 'pci/controller/ixp4xx'Bjorn Helgaas1-4/+6
- Use the PCI_CONF1_ADDRESS() macro to simplify config space address computation (Pali Rohár) * pci/controller/ixp4xx: PCI: ixp4xx: Use PCI_CONF1_ADDRESS() macro
2023-04-20Merge branch 'pci/controller/dwc'Bjorn Helgaas1-0/+7
- Install i.MX6 PCI abort handler only when DT contains a PCI controller claimed by the imx6 driver (H. Nikolaus Schaller) * pci/controller/dwc: PCI: imx6: Install the fault handler only on compatible match
2023-04-18PCI: Use of_property_present() for testing DT property presenceRob Herring2-3/+3
It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_property()/of_find_property() functions for reading properties. As part of this, convert of_get_property()/of_find_property() calls to the recently added of_property_present() helper when we just want to test for presence of a property and nothing more. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Herring <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> # pcie-mediatek
2023-04-17PCI: hv: Enable PCI pass-thru devices in Confidential VMsMichael Kelley1-64/+168
For PCI pass-thru devices in a Confidential VM, Hyper-V requires that PCI config space be accessed via hypercalls. In normal VMs, config space accesses are trapped to the Hyper-V host and emulated. But in a confidential VM, the host can't access guest memory to decode the instruction for emulation, so an explicit hypercall must be used. Add functions to make the new MMIO read and MMIO write hypercalls. Update the PCI config space access functions to use the hypercalls when such use is indicated by Hyper-V flags. Also, set the flag to allow the Hyper-V PCI driver to be loaded and used in a Confidential VM (a.k.a., "Isolation VM"). The driver has previously been hardened against a malicious Hyper-V host[1]. [1] https://lore.kernel.org/all/[email protected]/ Co-developed-by: Dexuan Cui <[email protected]> Signed-off-by: Dexuan Cui <[email protected]> Signed-off-by: Michael Kelley <[email protected]> Reviewed-by: Boqun Feng <[email protected]> Reviewed-by: Haiyang Zhang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]>
2023-04-12PCI: qcom: Add SM8550 PCIe supportAbel Vesa1-11/+14
SM8550 requires two additional clocks for proper working. Add these two clocks as optional clocks (as only required by this platform) and compatible for this platform. While at it, let's also rename the reset variable to "rst" from "pci_reset" to match the existing naming preference. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abel Vesa <[email protected]> [[email protected]: commit log rewording] Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Johan Hovold <[email protected]>
2023-04-12PCI: qcom: Add support for SDX55 SoCManivannan Sadhasivam1-1/+3
Add support for SDX55 SoC reusing the 1.9.0 config. The PCIe controller is of version 1.10.0 but it is compatible with the 1.9.0 config. This SoC also requires "sleep" clock which is added as an optional clock in the driver, since it is not required on other SoCs. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]>
2023-04-12PCI: qcom: Enable async probe by defaultManivannan Sadhasivam1-0/+1
Qcom PCIe RC driver waits for the PHY link to be up during the probe; this consumes several milliseconds during boot. Enable async probe by default so that other drivers can load in parallel while this driver waits for the link to be up. Suggested-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Johan Hovold <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Johan Hovold <[email protected]>
2023-04-12PCI: qcom: Add support for system suspend and resumeManivannan Sadhasivam1-0/+62
During the system suspend, vote for minimal interconnect bandwidth (1KiB) to keep the interconnect path active for config access and also turn OFF the resources like clock and PHY if there are no active devices connected to the controller. For the controllers with active devices, the resources are kept ON as removing the resources will trigger access violation during the late end of suspend cycle as kernel tries to access the config space of PCIe devices to mask the MSIs. Also, it is not desirable to put the link into L2/L3 state as that implies VDD supply will be removed and the devices may go into powerdown state. This will affect the lifetime of storage devices like NVMe. And finally, during resume, turn ON the resources if the controller was truly suspended (resources OFF) and update the interconnect bandwidth based on PCIe Gen speed. Suggested-by: Krishna chaitanya chundru <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Johan Hovold <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Johan Hovold <[email protected]> Acked-by: Dhruva Gole <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.