summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-07-09misc: pci_endpoint_test: Remove unused pci_endpoint_test_bar_{readl,writel} ↵Jiapeng Chong
functions These two functions are defined in the pci_endpoint_test.c file, but not called elsewhere, so delete these unused functions. This fixes the following warning: drivers/misc/pci_endpoint_test.c:144:19: warning: unused function 'pci_endpoint_test_bar_readl'. drivers/misc/pci_endpoint_test.c:150:20: warning: unused function 'pci_endpoint_test_bar_writel'. No functional changes intended. [kwilczynski: commit log] Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=9064 Link: https://lore.kernel.org/linux-pci/20240704023227.87039-1-jiapeng.chong@linux.alibaba.com Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-07-09misc: pci_endpoint_test: Document policy about adding pci_device_idYoshihiro Shimoda
Add a comment suggesting that if the endpoint controller Vendor and Device ID are programmable, an existing entry might be usable for testing without having to add an entry to pci_endpoint_test_tbl[]. Link: https://lore.kernel.org/linux-pci/20240611125057.1232873-6-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Frank Li <Frank.Li@nxp.com>
2024-07-09misc: pci_endpoint_test: Refactor dma_set_mask_and_coherent() logicFrank Li
dma_set_mask_and_coherent() should never fail when the mask is >= 32bit, unless the architecture has no DMA support. So no need to check for the error and also no need to set dma_set_mask_and_coherent(32) as a fallback. Even if dma_set_mask_and_coherent(48) fails due to the lack of DMA support (theoretically), then dma_set_mask_and_coherent(32) will also fail for the same reason. So the fallback doesn't make sense. Simplify the code by setting the streaming and coherent DMA mask to 48 bits. Link: https://lore.kernel.org/linux-pci/20240502195903.3191049-1-Frank.Li@nxp.com Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Niklas Cassel <cassel@kernel.org>
2024-07-09misc: pci_endpoint_test: Use memcpy_toio()/memcpy_fromio() for BAR testsNiklas Cassel
The current code uses writel()/readl(), which has an implicit memory barrier for every single readl()/writel(). Additionally, reading 4 bytes at a time over the PCI bus is not really optimal, considering that this code is running in an ioctl handler. Use memcpy_toio()/memcpy_fromio() for BAR tests. Before patch with a 4MB BAR: $ time /usr/bin/pcitest -b 1 BAR1: OKAY real 0m 1.56s After patch with a 4MB BAR: $ time /usr/bin/pcitest -b 1 BAR1: OKAY real 0m 0.54s Link: https://lore.kernel.org/linux-pci/20240322164139.678228-1-cassel@kernel.org Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
2024-07-09misc: pci_endpoint_test: Add support for Rockchip rk3588Niklas Cassel
Rockchip rk3588 requires 64KB alignment for BARs. While there is an existing device_id:vendor_id in the driver with 64KB alignment, that device_id:vendor_id is am654, which uses BAR2 instead of BAR0 as the test_reg_bar, and also has special is_am654_pci_dev() checks in the driver to disallow BAR0. In order to allow testing all BARs, add a new rk3588 entry in the driver. We intentionally do not add the vendor id to pci_ids.h, since the policy for that file is that the vendor id has to be used by multiple drivers. Hopefully, this new entry will be short-lived, as there is a series on the mailing list which intends to move the address alignment restrictions from this driver to the endpoint side. Add a new entry for rk3588 in order to allow us to test all BARs. Link: https://lore.kernel.org/linux-pci/20240607-rockchip-pcie-ep-v1-v5-11-0a042d6b0049@kernel.org Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-07-09PCI: kirin: Convert to use agnostic GPIO APIAndy Shevchenko
The of_gpio.h legacy API is going to be removed. In preparation for that, convert the driver to the agnostic API. [kwilczynski: commit log] Link: https://lore.kernel.org/linux-pci/20240506142142.4042810-6-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Rob Herring <robh@kernel.org>
2024-07-09PCI: kirin: Convert kirin_pcie_parse_port() to scoped iteratorJavier Carrasco
Convert loops in kirin_pcie_parse_port() to use the _scoped() version of for_each_available_child_of_node() so the refcounts of children are implicitly decremented when the loop is exited. No functional change intended here, but it will make future error exits from these loops easier. Link: https://lore.kernel.org/linux-pci/20240609-pcie-kirin-memleak-v1-1-62b45b879576@gmail.com Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> [bhelgaas: move to GPIO series to avoid bisection hole, commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-07-04dt-bindings: PCI: qcom: x1e80100: Make the MHI reg region mandatoryAbel Vesa
All PCIe controllers found on X1E80100 have MHI register region. So change the schema to reflect that. Fixes: 692eadd51698 ("dt-bindings: PCI: qcom: Document the X1E80100 PCIe Controller") Link: https://lore.kernel.org/linux-pci/20240605-x1e80100-pci-bindings-fix-v2-1-c465e87966fc@linaro.org Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-07-04dt-bindings: PCI: generic: Add ats-supported propertyJean-Philippe Brucker
Add a way for firmware to tell the OS that ATS is supported by the PCI root complex. An endpoint with ATS enabled may send Translation Requests and Translated Memory Requests, which look just like Normal Memory Requests with a non-zero AT field. So a root controller that ignores the AT field may simply forward the request to the IOMMU as a Normal Memory Request, which could end badly. In any case, the endpoint will be unusable. The ats-supported property allows the OS to only enable ATS in endpoints if the root controller can handle ATS requests. Only add the property to pcie-host-ecam-generic for the moment. For non-generic root controllers, availability of ATS can be inferred from the compatible string. Link: https://lore.kernel.org/linux-pci/20240607105415.2501934-3-jean-philippe@linaro.org Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
2024-07-04dt-bindings: PCI: mediatek,mt7621-pcie: Add PCIe host topology ASCII graphSergio Paracuellos
MediaTek MT7621 PCIe sub-system supports a single Root Complex (RC) with 3 Root Ports. Add PCIe host topology ASCII graph to the binding for completeness. Suggested-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/linux-pci/20240522044321.3205160-1-sergio.paracuellos@gmail.com Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-07-04dt-bindings: PCI: qcom: Add OPP tableKrishna chaitanya chundru
PCIe needs to choose the appropriate performance state of RPMh power domain based on the PCIe gen speed. Adding the Operating Performance Points table allows to adjust power domain performance state and ICC peak bw, depending on the PCIe data rate and link width. Link: https://lore.kernel.org/linux-pci/20240619-opp_support-v15-2-aa769a2173a3@quicinc.com Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-07-04dt-bindings: PCI: xilinx-cpm: Fix overlapping of bridge register and 32-bit ↵Thippeswamy Havalige
BAR addresses The current configuration had non-prefetchable memory overlapping with bridge registers by 64KB from base address. This patch fixes the 'ranges' property in the device tree by adjusting the non-prefetchable memory addresses beyond the 64KB mark to prevent conflicts. [kwilczynski: commit log] Link: https://lore.kernel.org/linux-pci/20240624111022.133780-1-thippesw@amd.com Signed-off-by: Thippeswamy Havalige <thippesw@amd.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-07-04dt-bindings: PCI: rockchip: Add DesignWare based PCIe Endpoint controllerNiklas Cassel
Document DT bindings for PCIe Endpoint controller found in Rockchip SoCs. Link: https://lore.kernel.org/linux-pci/20240607-rockchip-pcie-ep-v1-v5-6-0a042d6b0049@kernel.org Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
2024-07-04PCI: endpoint: Fix error handling in epf_ntb_epc_cleanup()Dan Carpenter
There are two issues related to epf_ntb_epc_cleanup(): 1) It should call epf_ntb_config_sspad_bar_clear() 2) The epf_ntb_bind() function should call epf_ntb_epc_cleanup() to cleanup. I also changed the ordering a bit. Unwinding should be done in the mirror order from how they are allocated. Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Link: https://lore.kernel.org/linux-pci/aaffbe8d-7094-4083-8146-185f4a84e8a1@moroto.mountain Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-07-04PCI: endpoint: Clean up error handling in vpci_scan_bus()Dan Carpenter
Smatch complains about inconsistent NULL checking in vpci_scan_bus(): drivers/pci/endpoint/functions/pci-epf-vntb.c:1024 vpci_scan_bus() error: we previously assumed 'vpci_bus' could be null (see line 1021) Instead of printing an error message and then crashing we should return an error code and clean up. Also the NULL check is reversed so it prints an error for success instead of failure. Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Link: https://lore.kernel.org/linux-pci/68e0f6a4-fd57-45d0-945b-0876f2c8cb86@moroto.mountain Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-07-04PCI: endpoint: Make pci_epc_class struct constantGreg Kroah-Hartman
Now that the driver core allows for struct class to be in read-only memory, we should make all 'class' structures declared at build time placing them into read-only memory, instead of having to be dynamically allocated at runtime. Link: https://lore.kernel.org/linux-pci/2024061011-citable-herbicide-1095@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
2024-07-04PCI: endpoint: Introduce 'epc_deinit' event and notify the EPF driversManivannan Sadhasivam
As like the 'epc_init' event, that is used to signal the EPF drivers about the EPC initialization, let's introduce 'epc_deinit' event that is used to signal EPC deinitialization. The EPC deinitialization applies only when any sort of fundamental reset is supported by the endpoint controller as per the PCIe spec. Reference: PCIe r6.0, sec 4.2.5.9.1 and 6.6.1. Currently, some EPC drivers like pcie-qcom-ep and pcie-tegra194 support PERST# as the fundamental reset. So the 'deinit' event will be notified to the EPF drivers when PERST# assert happens in the above mentioned EPC drivers. The EPF drivers, on receiving the event through the epc_deinit() callback should reset the EPF state machine and also cleanup any configuration that got affected by the fundamental reset like BAR, DMA etc... This change also warrants skipping the cleanups in unbind() if already done in epc_deinit(). Link: https://lore.kernel.org/r/20240606-pci-deinit-v1-2-4395534520dc@linaro.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Niklas Cassel <cassel@kernel.org> Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com> Reviewed-by: Frank Li <Frank.Li@nxp.com>
2024-07-03PCI: hv: Return zero, not garbage, when reading PCI_INTERRUPT_PINWei Liu
The intent of the code snippet is to always return 0 for both PCI_INTERRUPT_LINE and PCI_INTERRUPT_PIN. The check misses PCI_INTERRUPT_PIN. This patch fixes that. This is discovered by this call in VFIO: pci_read_config_byte(vdev->pdev, PCI_INTERRUPT_PIN, &pin); The old code does not set *val to 0 because it misses the check for PCI_INTERRUPT_PIN. Garbage is returned in that case. Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs") Link: https://lore.kernel.org/linux-pci/20240701202606.129606-1-wei.liu@kernel.org Signed-off-by: Wei Liu <wei.liu@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Cc: stable@kernel.org
2024-07-01PCI/DPC: Fix use-after-free on concurrent DPC and hot-removalLukas Wunner
Keith reports a use-after-free when a DPC event occurs concurrently to hot-removal of the same portion of the hierarchy: The dpc_handler() awaits readiness of the secondary bus below the Downstream Port where the DPC event occurred. To do so, it polls the config space of the first child device on the secondary bus. If that child device is concurrently removed, accesses to its struct pci_dev cause the kernel to oops. That's because pci_bridge_wait_for_secondary_bus() neglects to hold a reference on the child device. Before v6.3, the function was only called on resume from system sleep or on runtime resume. Holding a reference wasn't necessary back then because the pciehp IRQ thread could never run concurrently. (On resume from system sleep, IRQs are not enabled until after the resume_noirq phase. And runtime resume is always awaited before a PCI device is removed.) However starting with v6.3, pci_bridge_wait_for_secondary_bus() is also called on a DPC event. Commit 53b54ad074de ("PCI/DPC: Await readiness of secondary bus after reset"), which introduced that, failed to appreciate that pci_bridge_wait_for_secondary_bus() now needs to hold a reference on the child device because dpc_handler() and pciehp may indeed run concurrently. The commit was backported to v5.10+ stable kernels, so that's the oldest one affected. Add the missing reference acquisition. Abridged stack trace: BUG: unable to handle page fault for address: 00000000091400c0 CPU: 15 PID: 2464 Comm: irq/53-pcie-dpc 6.9.0 RIP: pci_bus_read_config_dword+0x17/0x50 pci_dev_wait() pci_bridge_wait_for_secondary_bus() dpc_reset_link() pcie_do_recovery() dpc_handler() Fixes: 53b54ad074de ("PCI/DPC: Await readiness of secondary bus after reset") Closes: https://lore.kernel.org/r/20240612181625.3604512-3-kbusch@meta.com/ Link: https://lore.kernel.org/linux-pci/8e4bcd4116fd94f592f2bf2749f168099c480ddf.1718707743.git.lukas@wunner.de Reported-by: Keith Busch <kbusch@kernel.org> Tested-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: stable@vger.kernel.org # v5.10+
2024-06-28PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)Kishon Vijay Abraham I
Errata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0 (SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an inbound PCIe TLP spans more than two internal AXI 128-byte bursts, the bus may corrupt the packet payload and the corrupt data may cause associated applications or the processor to hang. The workaround for Errata #i2037 is to limit the maximum read request size and maximum payload size to 128 bytes. Add workaround for Errata #i2037 here. The errata and workaround is applicable only to AM65x SR 1.0 and later versions of the silicon will have this fixed. [1] -> https://www.ti.com/lit/er/sprz452i/sprz452i.pdf Link: https://lore.kernel.org/linux-pci/16e1fcae-1ea7-46be-b157-096e05661b15@siemens.com Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Achal Verma <a-verma1@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
2024-06-25PCI: ls-gen4: Make struct mobiveil_rp_ops constantChristophe JAILLET
The struct mobiveil_rp_ops is not modified in this driver. Thus, make this struct constant, which also moves data to a read-only section decreasing object size and also improving overall security. On a x86_64, with allmodconfig, as an example: Before: ====== text data bss dec hex filename 4446 336 32 4814 12ce drivers/pci/controller/mobiveil/pcie-layerscape-gen4.o After: ===== text data bss dec hex filename 4454 328 32 4814 12ce drivers/pci/controller/mobiveil/pcie-layerscape-gen4.o [kwilczynski: commit log] Link: https://lore.kernel.org/linux-pci/189fd881cc8fd80220e74e91820e12cf3a5be114.1719260294.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
2024-06-21dt-bindings: PCI: rockchip-dw-pcie: Fix description of legacy IRQNiklas Cassel
The descriptions of the combined interrupt signals (level1) mention all the lower interrupt signals (level2) for each combined interrupt, regardless if the lower (level2) signal is RC or EP specific. E.g. the description of "Combined system interrupt" includes rbar_update, which is EP specific, and the description of "Combined message interrupt" includes obff_idle, obff_obff, obff_cpu_active, which are all EP specific. The only exception is the "Combined legacy interrupt", which for some reason does not provide an exhaustive list of the lower (level2) signals. Add the missing lower interrupt signals: tx_inta, tx_intb, tx_intc, and tx_intd for the "Combined legacy interrupt", as per the rk3568 and rk3588 Technical Reference Manuals, such that the descriptions of the combined interrupt signals are consistent. Link: https://lore.kernel.org/linux-pci/20240607-rockchip-pcie-ep-v1-v5-5-0a042d6b0049@kernel.org Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
2024-06-21dt-bindings: PCI: rockchip-dw-pcie: Prepare for Endpoint mode supportNiklas Cassel
Refactor the rockchip-dw-pcie binding to move generic properties to a new rockchip-dw-pcie-common binding that can be shared by both RC and EP mode. No functional change intended. Link: https://lore.kernel.org/linux-pci/20240607-rockchip-pcie-ep-v1-v5-4-0a042d6b0049@kernel.org Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
2024-06-21dt-bindings: PCI: snps,dw-pcie-ep: Add tx_int{a,b,c,d} legacy IRQsNiklas Cassel
The DWC core has four interrupt signals: tx_inta, tx_intb, tx_intc, tx_intd that are triggered when the PCIe controller (when running in Endpoint mode) has sent an Assert_INTA Message to the upstream device. Some DWC controllers have these interrupt in a combined interrupt signal. Add the description of these interrupts to the device tree binding. Link: https://lore.kernel.org/linux-pci/20240607-rockchip-pcie-ep-v1-v5-3-0a042d6b0049@kernel.org Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
2024-06-21dt-bindings: PCI: snps,dw-pcie-ep: Add vendor specific interrupt-namesNiklas Cassel
Considering that some drivers (e.g. pcie-dw-rockchip.c) already use the interrupt-names "sys", "pmc", "msg", "err" for the device tree binding in Root Complex mode (snps,dw-pcie.yaml), it doesn't make sense that those drivers should use different interrupt-names when running in Endpoint mode (snps,dw-pcie-ep.yaml). Therefore, since "sys", "pmc", "msg", "err" are already defined in snps,dw-pcie.yaml, add them also for snps,dw-pcie-ep.yaml. Link: https://lore.kernel.org/linux-pci/20240607-rockchip-pcie-ep-v1-v5-2-0a042d6b0049@kernel.org Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
2024-06-21dt-bindings: PCI: snps,dw-pcie-ep: Add vendor specific reg-nameNiklas Cassel
Considering that some drivers (e.g. pcie-dw-rockchip.c) already use the reg-name "apb" for the device tree binding in Root Complex mode (snps,dw-pcie.yaml), it doesn't make sense that those drivers should use a different reg-name when running in Endpoint mode (snps,dw-pcie-ep.yaml). Therefore, since "apb" is already defined in snps,dw-pcie.yaml, add it also for snps,dw-pcie-ep.yaml. Link: https://lore.kernel.org/linux-pci/20240607-rockchip-pcie-ep-v1-v5-1-0a042d6b0049@kernel.org Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
2024-06-18PCI/DPC: Disable DPC service on suspendKai-Heng Feng
If the link is powered off during suspend, electrical noise may cause errors that trigger DPC. If the DPC interrupt is enabled and shares an IRQ with PME, that causes a spurious wakeup during suspend. Disable DPC triggering and the DPC interrupt during suspend to prevent this. Clear DPC interrupt status before re-enabling DPC interrupts during resume so we don't get an interrupt for errors that occurred during the suspend/resume process. Link: https://bugzilla.kernel.org/show_bug.cgi?id=209149 Link: https://bugzilla.kernel.org/show_bug.cgi?id=216295 Link: https://bugzilla.kernel.org/show_bug.cgi?id=218090 Link: https://lore.kernel.org/r/20240416043225.1462548-3-kai.heng.feng@canonical.com Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> [bhelgaas: clear status on resume, add comments, commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-06-18PCI/AER: Disable AER service on suspendKai-Heng Feng
If the link is powered off during suspend, electrical noise may cause errors that are logged via AER. If the AER interrupt is enabled and shares an IRQ with PME, that causes a spurious wakeup during suspend. Disable the AER interrupt during suspend to prevent this. Clear error status before re-enabling IRQ interrupts during resume so we don't get an interrupt for errors that occurred during the suspend/resume process. Link: https://bugzilla.kernel.org/show_bug.cgi?id=209149 Link: https://bugzilla.kernel.org/show_bug.cgi?id=216295 Link: https://bugzilla.kernel.org/show_bug.cgi?id=218090 Link: https://lore.kernel.org/r/20240416043225.1462548-2-kai.heng.feng@canonical.com Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> [bhelgaas: drop pci_ancestor_pr3_present() etc, commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-06-18PCI: acpiphp: Add missing MODULE_DESCRIPTION() macroJeff Johnson
With ARCH=arm64, make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pci/hotplug/acpiphp_ampere_altra.o Add the missing MODULE_DESCRIPTION(). Link: https://lore.kernel.org/r/20240612-md-drivers-pci-hotplug-v1-1-2b30d14d783d@quicinc.com Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-06-12PCI: Relax bridge window tail sizing rulesIlpo Järvinen
During remove & rescan cycle, PCI subsystem will recalculate and adjust the bridge window sizing that was initially done by "BIOS". The size calculation is based on the required alignment of the largest resource among the downstream resources as per pbus_size_mem() (unimportant or zero parameters marked with "..."): min_align = calculate_mem_align(aligns, max_order); size0 = calculate_memsize(size, ..., min_align); inside calculate_memsize(), for the largest alignment: min_align = align1 >> 1; ... return min_align; and then in calculate_memsize(): return ALIGN(max(size, ...), align); If the original bridge window sizing tried to conserve space, this will lead to massive increase of the required bridge window size when the downstream has a large disparity in BAR sizes. E.g., with 16MiB and 16GiB BARs this results in 24GiB bridge window size even if 16MiB BAR does not require gigabytes of space to fit. When doing remove & rescan for a bus that contains such a PCI device, a larger bridge window is suddenly required on rescan but when there is a bridge window upstream that is already assigned based on the original size, it cannot be enlarged to the new requirement. This causes the allocation of the bridge window to fail (0x600000000 > 0x400ffffff): pci 0000:02:01.0: PCI bridge to [bus 03] pci 0000:02:01.0: bridge window [mem 0x40400000-0x405fffff] pci 0000:02:01.0: bridge window [mem 0x6000000000-0x6400ffffff 64bit pref] pci 0000:01:00.0: PCI bridge to [bus 02-04] pci 0000:01:00.0: bridge window [mem 0x40400000-0x406fffff] pci 0000:01:00.0: bridge window [mem 0x6000000000-0x6400ffffff 64bit pref] pci 0000:03:00.0: device released pci 0000:02:01.0: device released pcieport 0000:01:00.0: scanning [bus 02-04] behind bridge, pass 0 pci 0000:02:01.0: PCI bridge to [bus 03] pci 0000:02:01.0: bridge window [mem 0x40400000-0x405fffff] pci 0000:02:01.0: bridge window [mem 0x6000000000-0x6400ffffff 64bit pref] pci 0000:02:01.0: scanning [bus 03-03] behind bridge, pass 0 pci 0000:03:00.0: BAR 0 [mem 0x6400000000-0x6400ffffff 64bit pref] pci 0000:03:00.0: BAR 2 [mem 0x6000000000-0x63ffffffff 64bit pref] pci 0000:03:00.0: ROM [mem 0x40400000-0x405fffff pref] pci 0000:02:01.0: PCI bridge to [bus 03] pci 0000:02:01.0: scanning [bus 03-03] behind bridge, pass 1 pcieport 0000:01:00.0: scanning [bus 02-04] behind bridge, pass 1 pci 0000:02:01.0: bridge window [mem size 0x600000000 64bit pref]: can't assign; no space pci 0000:02:01.0: bridge window [mem size 0x600000000 64bit pref]: failed to assign pci 0000:02:01.0: bridge window [mem 0x40400000-0x405fffff]: assigned pci 0000:03:00.0: BAR 2 [mem size 0x400000000 64bit pref]: can't assign; no space pci 0000:03:00.0: BAR 2 [mem size 0x400000000 64bit pref]: failed to assign pci 0000:03:00.0: BAR 0 [mem size 0x01000000 64bit pref]: can't assign; no space pci 0000:03:00.0: BAR 0 [mem size 0x01000000 64bit pref]: failed to assign pci 0000:03:00.0: ROM [mem 0x40400000-0x405fffff pref]: assigned pci 0000:02:01.0: PCI bridge to [bus 03] pci 0000:02:01.0: bridge window [mem 0x40400000-0x405fffff] This is a major surprise for users who are suddenly left with a device that was working fine with the original bridge window sizing. Even if the already assigned bridge window could be enlarged by reallocation in some cases (something the current code does not attempt to do), it is not possible in general case and the large amount of wasted space at the tail of the bridge window may lead to other resource exhaustion problems on Root Complex level (think of multiple PCIe cards with VFs and BAR size disparity in a single system). PCI BARs only need natural alignment (PCIe r6.1, sec 7.5.1.2.1) and bridge memory windows need 1MiB (sec 7.5.1.3). The current bridge window tail alignment rule was introduced in the commit 5d0a8965aea9 ("[PATCH] 2.5.14: New PCI allocation code (alpha, arm, parisc) [2/2]") that only states: "pbus_size_mem: core stuff; tested with randomly generated sets of resources". It does not explain the motivation for the extra tail space allocated that is not truly needed by the downstream resources. As such, it is far from clear if it ever has been required by any HW. To prevent devices with BAR size disparity from becoming unusable after remove & rescan cycle, attempt to do a truly minimal allocation for memory resources if needed. First check if the normally calculated bridge window will not fit into an already assigned upstream resource. In such case, try with relaxed bridge window tail sizing rules instead where no extra tail space is requested beyond what the downstream resources require. Only enforce the alignment requirement of the bridge window itself (normally 1MiB). With this patch, the resources are successfully allocated: pci 0000:02:01.0: PCI bridge to [bus 03] pci 0000:02:01.0: scanning [bus 03-03] behind bridge, pass 1 pcieport 0000:01:00.0: scanning [bus 02-04] behind bridge, pass 1 pcieport 0000:01:00.0: Assigned bridge window [mem 0x6000000000-0x6400ffffff 64bit pref] to [bus 02-04] cannot fit 0x600000000 required for 0000:02:01.0 bridging to [bus 03] pci 0000:02:01.0: bridge window [mem 0x6000000000-0x6400ffffff 64bit pref] to [bus 03] requires relaxed alignment rules pcieport 0000:01:00.0: Assigned bridge window [mem 0x40400000-0x406fffff] to [bus 02-04] free space at [mem 0x40400000-0x405fffff] pci 0000:02:01.0: bridge window [mem 0x6000000000-0x6400ffffff 64bit pref]: assigned pci 0000:02:01.0: bridge window [mem 0x40400000-0x405fffff]: assigned pci 0000:03:00.0: BAR 2 [mem 0x6000000000-0x63ffffffff 64bit pref]: assigned pci 0000:03:00.0: BAR 0 [mem 0x6400000000-0x6400ffffff 64bit pref]: assigned pci 0000:03:00.0: ROM [mem 0x40400000-0x405fffff pref]: assigned pci 0000:02:01.0: PCI bridge to [bus 03] pci 0000:02:01.0: bridge window [mem 0x40400000-0x405fffff] pci 0000:02:01.0: bridge window [mem 0x6000000000-0x6400ffffff 64bit pref] This patch draws inspiration from the initial investigations and work by Mika Westerberg. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=216795 Link: https://lore.kernel.org/linux-pci/20190812144144.2646-1-mika.westerberg@linux.intel.com/ Fixes: 5d0a8965aea9 ("[PATCH] 2.5.14: New PCI allocation code (alpha, arm, parisc) [2/2]") Link: https://lore.kernel.org/r/20240507102523.57320-9-ilpo.jarvinen@linux.intel.com Tested-by: Lidong Wang <lidong.wang@intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-06-12PCI: Make minimum bridge window alignment reference more obviousIlpo Järvinen
Calculations related to bridge window size contain literal 20 that is the minimum alignment for a bridge window. Make the code more obvious by converting the literal 20 to __ffs(SZ_1M). Link: https://lore.kernel.org/r/20240507102523.57320-8-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> [bhelgaas: squash https://lore.kernel.org/r/20240612093250.17544-1-ilpo.jarvinen@linux.intel.com] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-06-04PCI: Warn on missing cfg_access_lock during secondary bus resetDan Williams
The recent adventure with adding lockdep tracking for cfg_access_lock, while it yielded many false positives [1], did catch a true positive in the pci_reset_bus() path [2]. So, while lockdep is difficult to deploy, open coding a check that cfg_access_lock is held during the reset is feasible. While this does not offer a full backtrace, it should be sufficient to implicate the caller of pci_bridge_secondary_bus_reset() as a path that needs investigation. Link: https://lore.kernel.org/r/171711746953.1628941.4692125082286867825.stgit@dwillia2-xfh.jf.intel.com Link: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_134186v1/shard-dg2-1/igt@device_reset@unbind-reset-rebind.html [1] Link: http://lore.kernel.org/r/cfb50601-5d2a-4676-a958-1bd3f1b06654@intel.com [2] Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Kalle Valo <kvalo@kernel.org> Reviewed-by: Dave Jiang <dave.jiang@intel.com>
2024-06-03PCI: Use preserve_config in place of pci_flagsVidya Sagar
Use preserve_config in place of checking for PCI_PROBE_ONLY flag to enable support for "linux,pci-probe-only" on a per host bridge basis. This also obviates the use of adding PCI_REASSIGN_ALL_BUS flag if !PCI_PROBE_ONLY, as pci_assign_unassigned_root_bus_resources() takes care of reassigning the resources that are not already claimed. Link: https://lore.kernel.org/r/20240508174138.3630283-5-vidyas@nvidia.com Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-06-03PCI: Unify ACPI and DT 'preserve config' supportVidya Sagar
Unify the 'preserve config' support across ACPI and device-tree boot flows. Link: https://lore.kernel.org/r/20240508174138.3630283-4-vidyas@nvidia.com Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-06-03PCI: of: Add of_pci_preserve_config() for per-host bridge supportVidya Sagar
Add of_pci_preserve_config() to look for the "linux,pci-probe-only" property under a specified node. If it's not found there, look under "of_chosen" in addition. If the caller didn't specify a node, look under "of_chosen". With a future patch, this will support "linux,pci-probe-only" on a per host bridge basis based on the presence of the property in the respective PCI host bridge DT node. Implement of_pci_check_probe_only() using of_pci_preserve_config(). Link: https://lore.kernel.org/r/20240508174138.3630283-3-vidyas@nvidia.com Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-06-03PCI: Move PRESERVE_BOOT_CONFIG _DSM evaluation to pci_register_host_bridge()Vidya Sagar
Move the PRESERVE_BOOT_CONFIG _DSM evaluation from acpi_pci_root_create() to pci_register_host_bridge(). This will help unify the ACPI _DSM path and the DT-based "linux,pci-probe-only" paths. This should be safe because it happens earlier than it used to: acpi_pci_root_create pci_create_root_bus pci_register_host_bridge + bridge->preserve_config = pci_preserve_config(bridge) pci_acpi_preserve_config + acpi_evaluate_dsm_typed(DSM_PCI_PRESERVE_BOOT_CONFIG) - acpi_evaluate_dsm_typed(DSM_PCI_PRESERVE_BOOT_CONFIG) No functional change intended. Link: https://lore.kernel.org/r/20240508174138.3630283-2-vidyas@nvidia.com Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-05-30PCI: pciehp: Detect device replacement during system sleepLukas Wunner
Ricky reports that replacing a device in a hotplug slot during ACPI sleep state S3 does not cause re-enumeration on resume, as one would expect. Instead, the new device is treated as if it was the old one. There is no bulletproof way to detect device replacement, but as a heuristic, check whether the device identity in config space matches cached data in struct pci_dev (Vendor ID, Device ID, Class Code, Revision ID, Subsystem Vendor ID, Subsystem ID). Additionally, cache and compare the Device Serial Number (PCIe r6.2 sec 7.9.3). If a mismatch is detected, mark the old device disconnected (to prevent its driver from accessing the new device) and synthesize a Presence Detect Changed event. The device identity in config space which is compared here is the same as the one included in the signed Subject Alternative Name per PCIe r6.1 sec 6.31.3. Thus, the present commit prevents attacks where a valid device is replaced with a malicious device during system sleep and the valid device's driver obliviously accesses the malicious device. This is about as much as can be done at the PCI layer. Drivers may have additional ways to identify devices (such as reading a WWID from some register) and may trigger re-enumeration when detecting an identity change on resume. Link: https://lore.kernel.org/r/a1afaa12f341d146ecbea27c1743661c71683833.1716992815.git.lukas@wunner.de Reported-by: Ricky Wu <ricky_wu@realtek.com> Closes: https://lore.kernel.org/r/a608b5930d0a48f092f717c0e137454b@realtek.com Tested-by: Ricky Wu <ricky_wu@realtek.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-05-28PCI: endpoint: pci-epf-test: Handle Link Down eventManivannan Sadhasivam
Per PCIe r6.0, sec 5.2, a Link Down event can happen under any of the following circumstances: 1. Fundamental/Hot reset 2. Link disable transmission by upstream component 3. Moving from L2/L3 to L0 When the event happens, the EPC driver capable of detecting it may pass the notification to the EPF driver through link_down() callback in 'struct pci_epc_event_ops'. While the PCIe spec has not defined the actual behavior of the endpoint when the Link Down event happens, we may assume that at least the ongoing transactions need to be stopped as the link won't be active, so cancel the command handler work in the callback implementation pci_epf_test_link_down(). The work will be started again in pci_epf_test_link_up() once the link comes back again. Link: https://lore.kernel.org/linux-pci/20240430-pci-epf-rework-v4-10-22832d0d456f@linaro.org Tested-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> [bhelgaas: update spec citation] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Niklas Cassel <cassel@kernel.org>
2024-05-28PCI: starfive: Add JH7110 PCIe controllerMinda Chen
Add StarFive JH7110 SoC PCIe controller platform driver code, JH7110 with PLDA host PCIe core. Link: https://lore.kernel.org/linux-pci/20240328091835.14797-22-minda.chen@starfivetech.com Co-developed-by: Kevin Xie <kevin.xie@starfivetech.com> Signed-off-by: Minda Chen <minda.chen@starfivetech.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Mason Huo <mason.huo@starfivetech.com>
2024-05-28dt-bindings: PCI: Add StarFive JH7110 PCIe controllerMinda Chen
Add StarFive JH7110 SoC PCIe controller dt-bindings. JH7110 uses PLDA XpressRICH PCIe host controller IP. Link: https://lore.kernel.org/linux-pci/20240328091835.14797-20-minda.chen@starfivetech.com Signed-off-by: Minda Chen <minda.chen@starfivetech.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Hal Feng <hal.feng@starfivetech.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Kevin Xie <kevin.xie@starfivetech.com>
2024-05-28PCI: Add PCIE_RESET_CONFIG_DEVICE_WAIT_MS waiting time valueKevin Xie
Add the PCIE_RESET_CONFIG_DEVICE_WAIT_MS macro to define the minimum waiting time between exit from a conventional reset and sending the first configuration request to the device. As described in PCIe r6.0, sec 6.6.1 <Conventional Reset>, there are two different use cases of the value: - "With a Downstream Port that does not support Link speeds greater than 5.0 GT/s, software must wait a minimum of 100 ms following exit from a Conventional Reset before sending a Configuration Request to the device immediately below that Port." - "With a Downstream Port that supports Link speeds greater than 5.0 GT/s, software must wait a minimum of 100 ms after Link training completes before sending a Configuration Request to the device immediately below that Port." [kwilczynski: commit log] Link: https://lore.kernel.org/linux-pci/20240328091835.14797-21-minda.chen@starfivetech.com Signed-off-by: Kevin Xie <kevin.xie@starfivetech.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Mason Huo <mason.huo@starfivetech.com>
2024-05-28PCI: plda: Pass pci_host_bridge to plda_pcie_setup_iomems()Minda Chen
plda_pcie_setup_iomems() needs the bridge->windows list from struct pci_host_bridge and is currently used only by pcie-microchip-host.c. This driver uses pci_host_common_probe(), which sets a pci_host_bridge as the drvdata, so plda_pcie_setup_iomems() used platform_get_drvdata() to find the pci_host_bridge. But we also want to use plda_pcie_setup_iomems() in the new pcie-starfive.c driver, which does not use pci_host_common_probe() and will have struct starfive_jh7110_pcie as its drvdata, so pass the pci_host_bridge directly to plda_pcie_setup_iomems() so it doesn't need platform_get_drvdata() to find it. Link: https://lore.kernel.org/linux-pci/20240328091835.14797-9-minda.chen@starfivetech.com Signed-off-by: Minda Chen <minda.chen@starfivetech.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> [bhelgaas: commit log, reorder to where this is needed] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
2024-05-28PCI: plda: Add host init/deinit and map bus functionsMinda Chen
Add PLDA host plda_pcie_host_init()/plda_pcie_host_deinit() and map bus function so vendors can use it to init PLDA PCIe host core. Link: https://lore.kernel.org/linux-pci/20240328091835.14797-19-minda.chen@starfivetech.com Signed-off-by: Minda Chen <minda.chen@starfivetech.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Mason Huo <mason.huo@starfivetech.com>
2024-05-28PCI: plda: Add event bitmap field to struct plda_pcie_rpMinda Chen
PLDA DMA interrupts are not all implemented, and the non-implemented interrupts should be masked. Add a bitmap field to mask the non-implemented interrupts. Link: https://lore.kernel.org/linux-pci/20240328091835.14797-18-minda.chen@starfivetech.com Signed-off-by: Minda Chen <minda.chen@starfivetech.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-05-28PCI: microchip: Move IRQ functions to pcie-plda-host.cMinda Chen
Move IRQ related functions to common file pcie-plda-host.c The re-use code including MSI, INTx, event interrupts and IRQ init functions. Link: https://lore.kernel.org/linux-pci/20240328091835.14797-17-minda.chen@starfivetech.com Signed-off-by: Minda Chen <minda.chen@starfivetech.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Conor Dooley <conor.dooley@microchip.com>
2024-05-28PCI: microchip: Add event irqchip field to host port and add PLDA irqchipMinda Chen
As the PLDA DT binding doc (Documentation/devicetree/bindings/pci/ plda,xpressrich3-axi-common.yaml) shows, PLDA PCIe contains an interrupt controller. Microchip PolarFire PCIe event IRQs include PLDA interrupts and PolarFire additional interrupts. The interrupt irqchip ops includes ack/mask/unmask interrupt ops, which will write correct registers. Microchip PolarFire PCIe additional interrupts require to write PolarFire SoC self-defined registers. So Microchip PCIe event irqchip ops can not be re-used. Microchip PolarFire PCIe additional interrupts (defined in drivers/pci/controller/plda/pcie-microchip-host.c): EVENT_PCIE_L2_EXIT EVENT_PCIE_HOTRST_EXIT EVENT_PCIE_DLUP_EXIT EVENT_SEC_TX_RAM_SEC_ERR EVENT_SEC_RX_RAM_SEC_ERR ... To support PLDA its own event IRQ process, implements PLDA irqchip ops and add event irqchip field to struct pcie_plda_rp. [kwilczynski: commit log] Link: https://lore.kernel.org/linux-pci/20240328091835.14797-16-minda.chen@starfivetech.com Signed-off-by: Minda Chen <minda.chen@starfivetech.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Conor Dooley <conor.dooley@microchip.com>
2024-05-28PCI: microchip: Add get_events() callback and PLDA get_event()Minda Chen
As PLDA DT binding doc (Documentation/devicetree/bindings/pci/ plda,xpressrich3-axi-common.yaml) showed, PLDA PCIe contains an interrupt controller. PolarFire implements its own PCIe interrupts, additional to the regular PCIe interrupts, due to lack of an MSI controller, so the interrupt to event number mapping is different to the PLDA regular interrupts, necessitating a custom get_events() implementation. Microchip PolarFire PCIe additional interrupts (defined in drivers/pci/controller/plda/pcie-microchip-host.c): EVENT_PCIE_L2_EXIT EVENT_PCIE_HOTRST_EXIT EVENT_PCIE_DLUP_EXIT EVENT_SEC_TX_RAM_SEC_ERR EVENT_SEC_RX_RAM_SEC_ERR ... plda_get_events() adds interrupt register to PLDA event num mapping codes. All the PLDA interrupts can be seen in new added graph. [kwilczynski: commit log] Link: https://lore.kernel.org/linux-pci/20240328091835.14797-15-minda.chen@starfivetech.com Signed-off-by: Minda Chen <minda.chen@starfivetech.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Conor Dooley <conor.dooley@microchip.com>
2024-05-28PCI: microchip: Add INTx and MSI event num to struct plda_eventMinda Chen
The INTx and MSI interrupt event num is different across platforms, so add two event num fields in struct plda_event. Link: https://lore.kernel.org/linux-pci/20240328091835.14797-14-minda.chen@starfivetech.com Signed-off-by: Minda Chen <minda.chen@starfivetech.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Conor Dooley <conor.dooley@microchip.com>
2024-05-28PCI: microchip: Add request_event_irq() callback functionMinda Chen
As the PLDA DT binding doc (Documentation/devicetree/bindings/pci/ plda,xpressrich3-axi-common.yaml) shows, the PLDA IP contains an interrupt controller. Microchip PolarFire add some interrupts based on PLDA interrupt controller. The Microchip PolarFire PCIe additional interrupts (defined in drivers/pci/controller/plda/pcie-microchip-host.c): EVENT_PCIE_L2_EXIT EVENT_PCIE_HOTRST_EXIT EVENT_PCIE_DLUP_EXIT EVENT_SEC_TX_RAM_SEC_ERR EVENT_SEC_RX_RAM_SEC_ERR ... Both event_cause[] and mc_event_handler() contain additional interrupt symbol names; these can not be re-used. Add a new plda_event_handler() function, which implements PLDA interrupt defalt handler, and add a request_event_irq() callback function for Microchip PolarFire additional interrupts. [kwilczynski, bhelgaas: commit log] Link: https://lore.kernel.org/linux-pci/20240328091835.14797-13-minda.chen@starfivetech.com Signed-off-by: Minda Chen <minda.chen@starfivetech.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Conor Dooley <conor.dooley@microchip.com>
2024-05-28PCI: microchip: Add num_events field to struct plda_pcie_rpMinda Chen
The number of events is different across platforms. In order to share interrupt processing code, add a variable that defines the number of events so that it can be set per-platform instead of hardcoding it. Link: https://lore.kernel.org/linux-pci/20240328091835.14797-12-minda.chen@starfivetech.com Signed-off-by: Minda Chen <minda.chen@starfivetech.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
generated by cgit (git 2.34.1) at 2025-09-28 03:06:45 +0000