aboutsummaryrefslogtreecommitdiff
path: root/drivers/pci/controller
AgeCommit message (Collapse)AuthorFilesLines
2024-01-15Merge branch 'pci/controller/dwc'Bjorn Helgaas31-193/+222
- Convert fu740 CONFIG_PCIE_FU740 dependency from SOC_SIFIVE to ARCH_SIFIVE (Conor Dooley) - Align iATU mapping for endpoint MSI-X (Niklas Cassel) - Drop "host_" prefix from struct dw_pcie_host_ops members (Yoshihiro Shimoda) - Drop "ep_" prefix from struct dw_pcie_ep_ops members (Yoshihiro Shimoda) - Rename struct dw_pcie_ep_ops.func_conf_select() to .get_dbi_offset() to be more descriptive (Yoshihiro Shimoda) - Add Endpoint DBI accessors to encapsulate offset lookups (Yoshihiro Shimoda) - Cast iproc and rcar-gen4 of_device_get_match_data() results to uintptr_t to avoid clang "cast to smaller integer type" warnings (Justin Stitt, Yoshihiro Shimoda) * pci/controller/dwc: PCI: rcar-gen4: Fix -Wvoid-pointer-to-enum-cast error PCI: iproc: Fix -Wvoid-pointer-to-enum-cast warning PCI: dwc: Add dw_pcie_ep_{read,write}_dbi[2] helpers PCI: dwc: Rename .func_conf_select to .get_dbi_offset in struct dw_pcie_ep_ops PCI: dwc: Rename .ep_init to .init in struct dw_pcie_ep_ops PCI: dwc: Drop host prefix from struct dw_pcie_host_ops members PCI: dwc: endpoint: Fix dw_pcie_ep_raise_msix_irq() alignment support PCI: dwc: Convert SOC_SIFIVE to ARCH_SIFIVE
2024-01-15Merge branch 'pci/controller/cadence'Bjorn Helgaas2-5/+42
- Add j721e DT and driver support for 'num-lanes' for devices that support x1, x2, or x4 Links (Matt Ranostay) - Add j721e DT compatible strings and driver support for j784s4 (Matt Ranostay) - Make TI J721E Kconfig depend on ARCH_K3 since the hardware is specific to those TI SoC parts (Peter Robinson) * pci/controller/cadence: PCI: j721e: Make TI J721E depend on ARCH_K3 PCI: j721e: Add TI J784S4 PCIe configuration PCI: j721e: Add PCIe 4x lane selection support PCI: j721e: Add per platform maximum lane settings dt-bindings: PCI: ti,j721e-pci-*: Add j784s4-pci-* compatible strings dt-bindings: PCI: ti,j721e-pci-*: Add checks for num-lanes
2024-01-15Merge branch 'pci/controller/broadcom'Bjorn Helgaas1-10/+86
- Add DT property "brcm,clkreq-mode" and driver support for different CLKREQ# modes (Jim Quinlan) * pci/controller/broadcom: PCI: brcmstb: Configure HW CLKREQ# mode appropriate for downstream device dt-bindings: PCI: brcmstb: Add property "brcm,clkreq-mode"
2024-01-11PCI: brcmstb: Configure HW CLKREQ# mode appropriate for downstream deviceJim Quinlan1-10/+86
The Broadcom STB/CM PCIe HW core, which is also used in RPi SOCs, must be deliberately set by the PCIe RC HW into one of three mutually exclusive modes: "safe" -- No CLKREQ# expected or required, refclk is always provided. This mode should work for all devices but is not be capable of any refclk power savings. "no-l1ss" -- CLKREQ# is expected to be driven by the downstream device for CPM and ASPM L0s and L1. Provides Clock Power Management, L0s, and L1, but cannot provide L1 substate (L1SS) power savings. If the downstream device connected to the RC is L1SS capable AND the OS enables L1SS, all PCIe traffic may abruptly halt, potentially hanging the system. "default" -- Bidirectional CLKREQ# between the RC and downstream device. Provides ASPM L0s, L1, and L1SS, but not compliant to provide Clock Power Management; specifically, may not be able to meet the T_CLRon max timing of 400ns as specified in "Dynamic Clock Control", section 3.2.5.2.2 of the PCIe Express Mini CEM 2.1 specification. This situation is atypical and should happen only with older devices. Previously, this driver always set the mode to "no-l1ss", as almost all STB/CM boards operate in this mode. But now there is interest in activating L1SS power savings from STB/CM customers, which requires "aspm" mode. In addition, a bug was filed for RPi4 CM platform because most devices did not work in "no-l1ss" mode. Note that the mode is specified by the DT property "brcm,clkreq-mode". If this property is omitted, then "default" mode is chosen. Note: Since L1 substates are now possible, a modification was made regarding an internal bus timeout: During long periods of the PCIe RC HW being in an L1SS sleep state, there may be a timeout on an internal bus access, even though there may not be any PCIe access involved. Such a timeout will cause a subsequent CPU abort. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217276 Link: https://lore.kernel.org/linux-pci/[email protected] Tested-by: Cyril Brulebois <[email protected]> Tested-by: Florian Fainelli <[email protected]> Signed-off-by: Jim Quinlan <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]>
2024-01-09PCI: mediatek-gen3: Fix translation window size calculationJianjun Wang1-35/+50
When using the fls() helper, the translation table should be a power of two; otherwise, the resulting value will not be correct. For example, given fls(0x3e00000) - 1 = 25, the PCIe translation window size will be set to 0x2000000 instead of the expected size 0x3e00000. Fix the translation window by splitting the MMIO space into multiple tables if its size is not a power of two. [kwilczynski: commit log] Link: https://lore.kernel.org/linux-pci/[email protected] Fixes: d3bf75b579b9 ("PCI: mediatek-gen3: Add MediaTek Gen3 driver for MT8192") Signed-off-by: Jianjun Wang <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
2024-01-09PCI: mediatek: Clear interrupt status before dispatching handlerqizhong cheng1-2/+8
We found a failure when using the iperf tool during WiFi performance testing, where some MSIs were received while clearing the interrupt status, and these MSIs cannot be serviced. The interrupt status can be cleared even if the MSI status remains pending. As such, given the edge-triggered interrupt type, its status should be cleared before being dispatched to the handler of the underling device. [kwilczynski: commit log, code comment wording] Link: https://lore.kernel.org/linux-pci/[email protected] Fixes: 43e6409db64d ("PCI: mediatek: Add MSI support for MT2712 and MT7622") Signed-off-by: qizhong cheng <[email protected]> Signed-off-by: Jianjun Wang <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> [bhelgaas: rewrap comment] Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Cc: <[email protected]>
2024-01-09PCI: keystone: Fix race condition when initializing PHYsSiddharth Vadapalli1-0/+9
The PCI driver invokes the PHY APIs using the ks_pcie_enable_phy() function. The PHY in this case is the Serdes. It is possible that the PCI instance is configured for two lane operation across two different Serdes instances, using one lane of each Serdes. In such a configuration, if the reference clock for one Serdes is provided by the other Serdes, it results in a race condition. After the Serdes providing the reference clock is initialized by the PCI driver by invoking its PHY APIs, it is not guaranteed that this Serdes remains powered on long enough for the PHY APIs based initialization of the dependent Serdes. In such cases, the PLL of the dependent Serdes fails to lock due to the absence of the reference clock from the former Serdes which has been powered off by the PM Core. Fix this by obtaining reference to the PHYs before invoking the PHY initialization APIs and releasing reference after the initialization is complete. Link: https://lore.kernel.org/linux-pci/[email protected] Fixes: 49229238ab47 ("PCI: keystone: Cleanup PHY handling") Signed-off-by: Siddharth Vadapalli <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Acked-by: Ravi Gunasekaran <[email protected]>
2024-01-08Merge tag 'x86-apic-2024-01-08' of ↵Linus Torvalds1-7/+0
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 apic updates from Ingo Molnar: - Clean up 'struct apic': - Drop ::delivery_mode - Drop 'enum apic_delivery_modes' - Drop 'struct local_apic' - Fix comments * tag 'x86-apic-2024-01-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/ioapic: Remove unfinished sentence from comment x86/apic: Drop struct local_apic x86/apic: Drop enum apic_delivery_modes x86/apic: Drop apic::delivery_mode
2024-01-08PCI: xilinx-xdma: Fix error code in xilinx_pl_dma_pcie_init_irq_domain()Harshit Mogalapalli1-1/+1
Currently, if the function irq_domain_add_linear() fails to allocate a new IRQ domain and returns NULL, we would then still return a success from the xilinx_pl_dma_pcie_init_irq_domain() function regardless, as the PTR_ERR(NULL) would return a value of zero. This is not a desirable outcome. Thus, fix the incorrect error code and return the -ENOMEM error code if the irq_domain_add_linear() fails to allocate a new IRQ domain. [kwilczynski: commit log] Link: https://lore.kernel.org/linux-pci/[email protected] Fixes: 8d786149d78c ("PCI: xilinx-xdma: Add Xilinx XDMA Root Port driver") Signed-off-by: Harshit Mogalapalli <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]>
2024-01-06PCI: xilinx-xdma: Fix uninitialized symbols in xilinx_pl_dma_pcie_setup_irq()Krzysztof Wilczyński1-2/+2
The error paths that follow calls to the devm_request_irq() functions within the xilinx_pl_dma_pcie_setup_irq() reference an uninitialized symbol each that also so happens to be incorrect. Thus, fix this omission and reference the correct variable when invoking a given dev_err() function following an error. This problem was found using smatch via the 0-DAY CI Kernel Test service: drivers/pci/controller/pcie-xilinx-dma-pl.c:638 xilinx_pl_dma_pcie_setup_irq() error: uninitialized symbol 'irq'. drivers/pci/controller/pcie-xilinx-dma-pl.c:645 xilinx_pl_dma_pcie_setup_irq() error: uninitialized symbol 'irq'. Fixes: 8d786149d78c ("PCI: xilinx-xdma: Add Xilinx XDMA Root Port driver") Link: https://lore.kernel.org/oe-kbuild/[email protected]/ Reported-by: kernel test robot <[email protected]> Reported-by: Dan Carpenter <[email protected]> Closes: https://lore.kernel.org/r/[email protected]/ Signed-off-by: Krzysztof Wilczyński <[email protected]>
2024-01-06PCI: rcar-gen4: Fix -Wvoid-pointer-to-enum-cast errorYoshihiro Shimoda1-1/+1
When building with clang 18 with the -Werror compiler option enabled, the following error will be reported: drivers/pci/controller/dwc/pcie-rcar-gen4.c:439:15: error: cast to smaller integer type 'enum dw_pcie_device_mode' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast] 439 | rcar->mode = (enum dw_pcie_device_mode)of_device_get_match_data(&rcar->pdev->dev); To fix this issue, cast the data the of_device_get_match_data() helper returns to uintptr_t rather than the dw_pcie_device_mode enum. [kwilczynski: commit log] Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Yoshihiro Shimoda <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]>
2024-01-06PCI: iproc: Fix -Wvoid-pointer-to-enum-cast warningJustin Stitt1-1/+1
When building with clang 18, the following warning will be reported: drivers/pci/controller/pcie-iproc-platform.c:54:15: warning: cast to smaller integer type 'enum iproc_pcie_type' from 'const void *' [-Wvoid-pointer-to-enum-cast] 55 | pcie->type = (enum iproc_pcie_type) of_device_get_match_data(dev); To fix this issue, cast the data the of_device_get_match_data() helper returns to uintptr_t rather than the iproc_pcie_type enum. [kwilczynski: commit log] Link: https://lore.kernel.org/linux-pci/[email protected] Link: https://github.com/ClangBuiltLinux/linux/issues/1910 Reported-by: Nathan Chancellor <[email protected]> Signed-off-by: Justin Stitt <[email protected]> Signed-off-by: Yoshihiro Shimoda <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]>
2024-01-06PCI: dwc: Add dw_pcie_ep_{read,write}_dbi[2] helpersYoshihiro Shimoda2-124/+153
The current code calculated some dbi[2] registers' offset by calling dw_pcie_ep_get_dbi[2]_offset() in each function. To improve the code readability, add dw_pcie_ep_{read,write}_dbi[2} and some data-width related helpers. Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Yoshihiro Shimoda <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Serge Semin <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]>
2024-01-06PCI: dwc: Rename .func_conf_select to .get_dbi_offset in struct dw_pcie_ep_opsYoshihiro Shimoda4-60/+59
Since the struct member .func_conf_select makes the intentions behind it difficult to ascertain from its name alone, rename it to .get_dbi_offset to make the intended usage more obvious. [kwilczynski: commmit log] Suggested-by: Manivannan Sadhasivam <[email protected]> Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Yoshihiro Shimoda <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Serge Semin <[email protected]>
2024-01-06PCI: dwc: Rename .ep_init to .init in struct dw_pcie_ep_opsYoshihiro Shimoda12-13/+13
Since the name of the dw_pcie_ep_ops struct makes it obvious that it's for the PCIe Endpoint, rename the struct member .ep_init to .init. [kwilczynski: commit log] Suggested-by: Serge Semin <[email protected]> Suggested-by: Manivannan Sadhasivam <[email protected]> Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Yoshihiro Shimoda <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Serge Semin <[email protected]> Reviewed-by: Srikanth Thokala <[email protected]> Acked-by: Jesper Nilsson <[email protected]> Acked-by: Kunihiko Hayashi <[email protected]>
2024-01-06PCI: dwc: Drop host prefix from struct dw_pcie_host_ops membersYoshihiro Shimoda23-47/+47
Since the name of the dw_pcie_host_ops struct makes it obvious that it's for the PCIe Host, drop the host prefix from the struct members. [kwilczynski: commit log] Suggested-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Yoshihiro Shimoda <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Serge Semin <[email protected]> Reviewed-by: Thomas Petazzoni <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Acked-by: Jesper Nilsson <[email protected]> Acked-by: Kunihiko Hayashi <[email protected]> Acked-by: Lei Chuanhua <[email protected]> Acked-by: Nobuhiro Iwamatsu <[email protected]>
2024-01-06PCI: j721e: Make TI J721E depend on ARCH_K3Peter Robinson1-0/+2
The J721E PCIe is hardware specific to TI SoC parts so add a dependency on that so it's available for those SoC parts and for compile testing but not necessarily everyone who enables the Cadence PCIe controller. Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Peter Robinson <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]>
2024-01-06PCI: j721e: Add TI J784S4 PCIe configurationMatt Ranostay1-0/+22
Add PCIe configuration for J784S4 SoC platform which has 4x lane support. Link: https://lore.kernel.org/linux-pci/[email protected] Tested-by: Achal Verma <[email protected]> Signed-off-by: Matt Ranostay <[email protected]> Signed-off-by: Achal Verma <[email protected]> Signed-off-by: Siddharth Vadapalli <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Roger Quadros <[email protected]>
2023-12-19PCI: xilinx-nwl: Use INTX instead of legacyDamien Le Moal1-26/+26
In the xilinx-nwl controller driver, change all use of "legacy" and "leg" to "intx", to match the term used in the PCI specifications. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Damien Le Moal <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
2023-12-19PCI: rockchip-host: Rename rockchip_pcie_legacy_int_handler()Damien Le Moal1-2/+2
Rename the function rockchip_pcie_legacy_int_handler() of the rockchip host driver to rockchip_pcie_intx_handler() to match the PCI_IRQ_INTX macro name used to control this function execution, and to match the term used in the PCI specifications. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Damien Le Moal <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
2023-12-19PCI: rockchip-ep: Use INTX instead of legacyDamien Le Moal1-8/+8
Rename the function rockchip_pcie_ep_send_legacy_irq() of the rockchip endpoint driver to rockchip_pcie_ep_send_intx_irq(). Uses of the term "legacy" are also replaced with "INTX" in comments. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Damien Le Moal <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
2023-12-19PCI: uniphier: Use INTX instead of legacyDamien Le Moal2-8/+8
In the Designware uniphier controller driver, including the endpoint driver, change all names using "legacy" to use "intx", to match the term used in the PCI specifications. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Damien Le Moal <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
2023-12-19PCI: tegra194: Use INTX instead of legacyDamien Le Moal1-5/+5
In the Designware tegra194 controller driver, change all names using "legacy" to use "intx", to match the term used in the PCI specifications. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Damien Le Moal <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
2023-12-19PCI: dw-rockchip: Rename rockchip_pcie_legacy_int_handler()Damien Le Moal1-2/+2
Rename the function rockchip_pcie_legacy_int_handler() to rockchip_pcie_intx_handler() to match the code managing INTX interrupts (e.g. intx_domain_ops) and the term used in the PCI specifications. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Damien Le Moal <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
2023-12-19PCI: keystone: Use INTX instead of legacyDamien Le Moal1-40/+37
In the Keystone controller driver, change all names using "legacy" to use "intx" instead, to match the term used in the PCI specifications. Given that the field legacy_intc_np of struct keystone_pcie is unused, this field is removed instead of being renamed. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Damien Le Moal <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
2023-12-19PCI: dwc: Rename dw_pcie_ep_raise_legacy_irq()Damien Le Moal7-10/+10
Rename the function dw_pcie_ep_raise_legacy_irq() of the Designware endpoint controller driver to dw_pcie_ep_raise_intx_irq() to match the name of the PCI_IRQ_INTX macro. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Damien Le Moal <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Serge Semin <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
2023-12-19PCI: cadence: Use INTX instead of legacyDamien Le Moal2-11/+11
In the Cadence endpoint controller driver, rename the function cdns_pcie_ep_send_legacy_irq() to cdns_pcie_ep_send_intx_irq() to match the macro PCI_IRQ_INTX name. Related comments and messages mentioning "legacy" are also changed to refer to "intx". Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Damien Le Moal <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
2023-12-19PCI: dra7xx: Rename dra7xx_pcie_raise_legacy_irq()Damien Le Moal1-2/+2
Rename the function dra7xx_pcie_raise_legacy_irq() to dra7xx_pcie_raise_intx_irq() to match the use of the PCI_IRQ_INTX macro. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Damien Le Moal <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
2023-12-18PCI: endpoint: Drop PCI_EPC_IRQ_XXX definitionsDamien Le Moal16-64/+54
linux/pci.h defines the IRQ flags PCI_IRQ_INTX, PCI_IRQ_MSI and PCI_IRQ_MSIX. Let's use these flags directly instead of the endpoint definitions provided by enum pci_epc_irq_type. This removes the need for defining this enum type completely. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Damien Le Moal <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Serge Semin <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Acked-by: Manivannan Sadhasivam <[email protected]>
2023-12-18PCI: xilinx-xdma: Remove redundant dev_err()Yang Li1-6/+2
There is no need to call the dev_err() function directly to print a custom message when handling an error from either the platform_get_irq() or platform_get_irq_byname() functions as both are going to display an appropriate error message in case of a failure. ./drivers/pci/controller/pcie-xilinx-dma-pl.c:688:2-9: line 688 is redundant because platform_get_irq() already prints an error ./drivers/pci/controller/pcie-xilinx-dma-pl.c:702:2-9: line 702 is redundant because platform_get_irq() already prints an error Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=7074 Link: https://lore.kernel.org/linux-pci/[email protected] Reported-by: Abaci Robot <[email protected]> Signed-off-by: Yang Li <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]>
2023-12-18PCI: dwc: endpoint: Fix dw_pcie_ep_raise_msix_irq() alignment supportNiklas Cassel1-0/+1
Commit 6f5e193bfb55 ("PCI: dwc: Fix dw_pcie_ep_raise_msix_irq() to get correct MSI-X table address") modified dw_pcie_ep_raise_msix_irq() to support iATUs which require a specific alignment. However, this support cannot have been properly tested. The whole point is for the iATU to map an address that is aligned, using dw_pcie_ep_map_addr(), and then let the writel() write to ep->msi_mem + aligned_offset. Thus, modify the address that is mapped such that it is aligned. With this change, dw_pcie_ep_raise_msix_irq() matches the logic in dw_pcie_ep_raise_msi_irq(). Link: https://lore.kernel.org/linux-pci/[email protected] Fixes: 6f5e193bfb55 ("PCI: dwc: Fix dw_pcie_ep_raise_msix_irq() to get correct MSI-X table address") Signed-off-by: Niklas Cassel <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Cc: [email protected] # 5.7 Cc: Kishon Vijay Abraham I <[email protected]>
2023-12-17PCI: kirin: Use devm_kasprintf() to dynamically allocate clock namesChristophe JAILLET1-8/+5
Use devm_kasprintf() instead of open coding it. This saves the need of an intermediate buffer. There was also no reason to use devm_kstrdup_const() as string is known to be constant. [kwilczynski: commit log, and add missing Reviewed-by tag] Link: https://lore.kernel.org/linux-pci/1bad6879083a7d836c8a47418a0afa22485e8f69.1700294127.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Ilpo Järvinen <[email protected]>
2023-12-16PCI: kirin: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). In the error path emit an error message replacing the (less useful) message by the core. Apart from the improved error message there is no change in behaviour. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Link: https://lore.kernel.org/linux-pci/c3a51791d54deaa818b8526975fc4e16ef1090ce.1701682617.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]>
2023-12-16PCI: keystone: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). In the error path emit an error message replacing the (less useful) message by the core. Apart from the improved error message there is no change in behaviour. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Link: https://lore.kernel.org/linux-pci/06612aff79dfb52d5b0b20129dff5e4b1f04d3a7.1701682617.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]>
2023-12-16PCI: exynos: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). In the error path emit an error message replacing the (less useful) message by the core. Apart from the improved error message there is no change in behaviour. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Link: https://lore.kernel.org/linux-pci/50de44ea8931465fd9cdc821854ea761cb43adf6.1701682617.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]>
2023-12-16PCI: dwc: Convert SOC_SIFIVE to ARCH_SIFIVEConor Dooley1-1/+1
As part of converting RISC-V SOC_FOO symbols to ARCH_FOO to match the use of such symbols on other architectures, convert the SiFive PCI drivers to use the newer symbol. Link: https://lore.kernel.org/linux-pci/20230918-safeness-cornflake-62278bc3aaaa@wendy Signed-off-by: Conor Dooley <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]>
2023-12-14PCI: rcar-host: Add support for optional regulatorsWolfram Sang1-1/+17
The KingFisher board has regulators for miniPCIe, so enable these optional regulators using devm. devm will automatically disable them when the driver releases the device. Order variables in reverse-xmas while we are here. [kwilczynski: update style to match rest of the code] Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Acked-by: Manivannan Sadhasivam <[email protected]>
2023-12-14PCI: rcar-gen4: Replace of_device.h with explicit of.h includeRob Herring1-1/+1
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it was merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. [kwilczynski: commit log] Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Rob Herring <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Yoshihiro Shimoda <[email protected]>
2023-12-13PCI: vmd: Remove usage of the deprecated ida_simple_xx() APIChristophe JAILLET1-3/+3
ida_alloc() and ida_free() should be preferred to the deprecated ida_simple_get() and ida_simple_remove(). This is less verbose. Link: https://lore.kernel.org/linux-pci/270f25cdc154f3b0309e57b2f6421776752e2170.1702230593.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]>
2023-12-13PCI: j721e: Add PCIe 4x lane selection supportMatt Ranostay1-2/+8
Add support for setting of two-bit field that allows selection of 4x lane PCIe which was previously limited to only 2x lanes. Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Matt Ranostay <[email protected]> Signed-off-by: Achal Verma <[email protected]> Signed-off-by: Siddharth Vadapalli <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Vignesh Raghavendra <[email protected]> Reviewed-by: Roger Quadros <[email protected]>
2023-12-13PCI: j721e: Add per platform maximum lane settingsMatt Ranostay1-3/+10
Various platforms have different maximum amount of lanes that can be selected. Add max_lanes to struct j721e_pcie to allow for detection of this which is needed to calculate the needed bitmask size for the possible lane count. Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Matt Ranostay <[email protected]> Signed-off-by: Achal Verma <[email protected]> Signed-off-by: Siddharth Vadapalli <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Ravi Gunasekaran <[email protected]>
2023-12-12PCI: layerscape: Add suspend/resume for ls1043aFrank Li1-1/+62
Add suspend/resume support for Layerscape LS1043a. In the suspend path, PME_Turn_Off message is sent to the endpoint to transition the link to L2/L3_Ready state. In this SoC, there is no way to check if the controller has received the PME_To_Ack from the endpoint or not. So to be on the safer side, the driver just waits for PCIE_PME_TO_L2_TIMEOUT_US before asserting the SoC specific PMXMTTURNOFF bit to complete the PME_Turn_Off handshake. Then the link would enter L2/L3 state depending on the VAUX supply. In the resume path, the link is brought back from L2 to L0 by doing a software reset. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Frank Li <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Acked-by: Roy Zang <[email protected]>
2023-12-12PCI: layerscape(ep): Rename pf_* as pf_lut_*Frank Li2-25/+25
'pf' and 'lut' are two different acronyms describing the same thing, basically it is a MMIO base address plus an offset. Rename them to avoid duplicate pf_* and lut_* naming schemes in the driver. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Frank Li <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Acked-by: Roy Zang <[email protected]>
2023-12-12PCI: layerscape: Add suspend/resume for ls1021aFrank Li1-3/+80
Add suspend/resume support for Layerscape LS1021a. In the suspend path, PME_Turn_Off message is sent to the endpoint to transition the link to L2/L3_Ready state. In this SoC, there is no way to check if the controller has received the PME_To_Ack from the endpoint or not. So to be on the safer side, the driver just waits for PCIE_PME_TO_L2_TIMEOUT_US before asserting the SoC specific PMXMTTURNOFF bit to complete the PME_Turn_Off handshake. Then the link would enter L2/L3 state depending on the VAUX supply. In the resume path, the link is brought back from L2 to L0 by doing a software reset. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Frank Li <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Acked-by: Roy Zang <[email protected]>
2023-12-12PCI: layerscape: Add function pointer for exit_from_l2()Frank Li1-2/+9
Since different SoCs require different sequences for exiting L2, let's add a separate "exit_from_l2()" callback to handle SoC specific sequences. Change ls_pcie_exit_from_l2() return value from void to int in order to propagate errors. Return an error if the exit_from_l2() callback fails in the resume flow. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Frank Li <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Acked-by: Roy Zang <[email protected]>
2023-12-11PCI: qcom: Clean up ASPM commentJohan Hovold1-1/+4
Break up the newly added ASPM comment so that it fits within the soft 80 character limit and becomes more readable. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2023-12-11PCI: qcom: Fix potential deadlock when enabling ASPMJohan Hovold1-1/+1
The qcom_pcie_enable_aspm() helper is called from pci_walk_bus() during host init to enable ASPM. Since pci_walk_bus() already holds a pci_bus_sem read lock, use pci_enable_link_state_locked() to enable link states in order to avoid a potential deadlock (e.g. in case someone takes a write lock before reacquiring the read lock). This issue was reported by lockdep: ============================================ WARNING: possible recursive locking detected 6.7.0-rc1 #4 Not tainted -------------------------------------------- kworker/u16:6/147 is trying to acquire lock: ffffbf3ff9d2cfa0 (pci_bus_sem){++++}-{3:3}, at: pci_enable_link_state+0x74/0x1e8 but task is already holding lock: ffffbf3ff9d2cfa0 (pci_bus_sem){++++}-{3:3}, at: pci_walk_bus+0x34/0xbc other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(pci_bus_sem); lock(pci_bus_sem); *** DEADLOCK *** Fixes: 9f4f3dfad8cf ("PCI: qcom: Enable ASPM for platforms supporting 1.9.0 ops") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johan Hovold <[email protected]> [bhelgaas: add "potential" in subject since the deadlock has only been reported by lockdep, include helper name in commit log] Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]>
2023-12-11PCI: vmd: Fix potential deadlock when enabling ASPMJohan Hovold1-1/+1
The vmd_pm_enable_quirk() helper is called from pci_walk_bus() during probe to enable ASPM for controllers with VMD_FEAT_BIOS_PM_QUIRK set. Since pci_walk_bus() already holds a pci_bus_sem read lock, use pci_enable_link_state_locked() to enable link states in order to avoid a potential deadlock (e.g. in case someone takes a write lock before reacquiring the read lock). Fixes: f492edb40b54 ("PCI: vmd: Add quirk to configure PCIe ASPM and LTR") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johan Hovold <[email protected]> [bhelgaas: add "potential" in subject since the deadlock has only been reported by lockdep, include helper name in commit log] Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Cc: <[email protected]> # 6.3 Cc: Michael Bottini <[email protected]> Cc: David E. Box <[email protected]>
2023-12-08PCI: loongson: Limit MRRS to 256Jiaxun Yang1-5/+41
This is a partial revert of 8b3517f88ff2 ("PCI: loongson: Prevent LS7A MRRS increases") for MIPS-based Loongson. Some MIPS Loongson systems don't support arbitrary Max_Read_Request_Size (MRRS) settings. 8b3517f88ff2 ("PCI: loongson: Prevent LS7A MRRS increases") worked around that by (1) assuming that firmware configured MRRS to the maximum supported value and (2) preventing the PCI core from increasing MRRS. Unfortunately, some firmware doesn't set that maximum MRRS correctly, which results in devices not being initialized correctly. One symptom, from the Debian report below, is this: ata4.00: exception Emask 0x0 SAct 0x20000000 SErr 0x0 action 0x6 frozen ata4.00: failed command: WRITE FPDMA QUEUED ata4.00: cmd 61/20:e8:00:f0:e1/00:00:00:00:00/40 tag 29 ncq dma 16384 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata4.00: status: { DRDY } ata4: hard resetting link Limit MRRS to 256 because MIPS Loongson with higher MRRS support is considered rare. This must be done at device enablement stage because the MRRS setting may get lost if PCI_COMMAND_MASTER on the parent bridge is cleared, and we are only sure parent bridge is enabled at this point. Fixes: 8b3517f88ff2 ("PCI: loongson: Prevent LS7A MRRS increases") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217680 Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035587 Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jiaxun Yang <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Huacai Chen <[email protected]> Cc: [email protected]
2023-11-21x86/apic: Drop apic::delivery_modeAndrew Cooper1-7/+0
This field is set to APIC_DELIVERY_MODE_FIXED in all cases, and is read exactly once. Fold the constant in uv_program_mmr() and drop the field. Searching for the origin of the stale HyperV comment reveals commit a31e58e129f7 ("x86/apic: Switch all APICs to Fixed delivery mode") which notes: As a consequence of this change, the apic::irq_delivery_mode field is now pointless, but this needs to be cleaned up in a separate patch. 6 years is long enough for this technical debt to have survived. [ bp: Fold in https://lore.kernel.org/r/[email protected] ] Signed-off-by: Andrew Cooper <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Steve Wahl <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.