summaryrefslogtreecommitdiffstats
path: root/drivers/pci
AgeCommit message (Collapse)AuthorFilesLines
2022-12-03PCI/AER: Add optional logging callback for correctable errorDave Jiang1-1/+7
Some new devices such as CXL devices may want to record additional error information on a corrected error. Add a callback to allow the PCI device driver to do additional logging such as providing additional stats for user space RAS monitoring. For CXL device, this is actually a need due to CXL needing to write to the CXL RAS capability structure correctable error status register in order to clear the unmasked correctable errors. See CXL spec rev3.0 8.2.4.16. Suggested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/166984619233.2804404.3966368388544312674.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2022-12-02Merge tag 'v6.1-rc7' into iommufd.git for-nextJason Gunthorpe1-20/+90
Resolve conflicts in drivers/vfio/vfio_main.c by using the iommfd version. The rc fix was done a different way when iommufd patches reworked this code. Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2022-11-28PCI: hv: update comment in x86 specific hv_arch_irq_unmaskOlaf Hering1-3/+3
The function hv_set_affinity was removed in commit 831c1ae7 ("PCI: hv: Make the code arch neutral by adding arch specific interfaces"). Signed-off-by: Olaf Hering <olaf@aepfle.de> Link: https://lore.kernel.org/r/20221107171831.25283-1-olaf@aepfle.de Signed-off-by: Wei Liu <wei.liu@kernel.org>
2022-11-23PCI: endpoint: pci-epf-vntb: Fix sparse ntb->reg build warningFrank Li1-4/+4
pci-epf-vntb.c:1128:33: sparse: expected void [noderef] __iomem *base pci-epf-vntb.c:1128:33: sparse: got struct epf_ntb_ctrl *reg Add __iomem type cast in vntb_epf_peer_spad_read() and vntb_epf_peer_spad_write(). Link: https://lore.kernel.org/r/20221102141014.1025893-8-Frank.Li@nxp.com Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Frank Li <frank.li@nxp.com> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Acked-by: Manivannan Sadhasivam <mani@kernel.org>
2022-11-23PCI: endpoint: pci-epf-vntb: Fix sparse build warning for epf_dbFrank Li1-6/+4
Use epf_db[i] dereference instead of readl() because epf_db is in memory allocated by dma_alloc_coherent(), not I/O. Remove useless/duplicated readl() in the process. Link: https://lore.kernel.org/r/20221102141014.1025893-7-Frank.Li@nxp.com Signed-off-by: Frank Li <frank.li@nxp.com> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
2022-11-23PCI: endpoint: pci-epf-vntb: Replace hardcoded 4 with sizeof(u32)Frank Li1-12/+12
NTB spad entry item size is sizeof(u32), replace hardcoded 4 with it. Link: https://lore.kernel.org/r/20221102141014.1025893-6-Frank.Li@nxp.com Signed-off-by: Frank Li <frank.li@nxp.com> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Acked-by: Manivannan Sadhasivam <mani@kernel.org>
2022-11-23PCI: endpoint: pci-epf-vntb: Remove unused epf_db_phy struct memberFrank Li1-1/+0
epf_db_phy member in struct epf_ntb is not used, remove it. Link: https://lore.kernel.org/r/20221102141014.1025893-5-Frank.Li@nxp.com Signed-off-by: Frank Li <frank.li@nxp.com> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Acked-by: Manivannan Sadhasivam <mani@kernel.org>
2022-11-23PCI: endpoint: pci-epf-vntb: Fix call pci_epc_mem_free_addr() in error pathFrank Li1-1/+1
Replace pci_epc_mem_free_addr() with pci_epf_free_space() in the error handle path to match pci_epf_alloc_space(). Link: https://lore.kernel.org/r/20221102141014.1025893-4-Frank.Li@nxp.com Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Signed-off-by: Frank Li <frank.li@nxp.com> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
2022-11-23PCI: endpoint: pci-epf-vntb: Fix struct epf_ntb_ctrl indentationFrank Li1-14/+14
Align the indentation of struct epf_ntb_ctrl with other structs in the driver. Link: https://lore.kernel.org/r/20221102141014.1025893-3-Frank.Li@nxp.com Signed-off-by: Frank Li <frank.li@nxp.com> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
2022-11-23PCI: endpoint: pci-epf-vntb: Clean up kernel_doc warningFrank Li1-29/+54
Cleanup warning found by scripts/kernel-doc. Consolidate terms: - host, host1 to HOST - vhost, vHost, Vhost, VHOST2 to VHOST Link: https://lore.kernel.org/r/20221102141014.1025893-2-Frank.Li@nxp.com Signed-off-by: Frank Li <frank.li@nxp.com> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Acked-by: Manivannan Sadhasivam <mani@kernel.org>
2022-11-23PCI: dwc: Add Baikal-T1 PCIe controller supportSerge Semin3-0/+653
Baikal-T1 SoC is equipped with DWC PCIe v4.60a host controller. It can be trained to work up to Gen.3 speed over up to x4 lanes. The host controller is attached to the DW PCIe 3.0 PCS via the PIPE-4 interface, which in its turn is connected to the DWC 10G PHY. The whole system is supposed to be fed up with four clock sources: DBI peripheral clock, AXI application clocks and external PHY/core reference clock generating the 100MHz signal. In addition to that the platform provide a way to reset each part of the controller: sticky/non-sticky bits, host controller core, PIPE interface, PCS/PHY and Hot/Power reset signal. The driver also provides a way to handle the GPIO-based PERST# signal. Note due to the Baikal-T1 MMIO peculiarity we have to implement the DBI interface accessors which make sure the IO operations are dword-aligned. Link: https://lore.kernel.org/r/20221113191301.5526-21-Sergey.Semin@baikalelectronics.ru Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
2022-11-23PCI: dwc: Introduce generic platform clocks and resetsSerge Semin2-0/+133
Currently almost each platform driver uses its own resets and clocks naming in order to get the corresponding descriptors. It makes the code harder to maintain and comprehend especially seeing the DWC PCIe core main resets and clocks signals set hasn't changed much for about at least one major IP-core release. So in order to organize things around these signals we suggest to create a generic interface for them in accordance with the naming introduced in the DWC PCIe IP-core reference manual: Application clocks: - "dbi" - data bus interface clock (on some DWC PCIe platforms it's referred as "pclk", "pcie", "sys", "ahb", "cfg", "iface", "gio", "reg", "pcie_apb_sys"); - "mstr" - AXI-bus master interface clock (some DWC PCIe glue drivers refer to this clock as "port", "bus", "pcie_bus", "bus_master/master_bus/axi_m", "pcie_aclk"); - "slv" - AXI-bus slave interface clock (also called as "port", "bus", "pcie_bus", "bus_slave/slave_bus/axi_s", "pcie_aclk", "pcie_inbound_axi"). Core clocks: - "pipe" - core-PCS PIPE interface clock coming from external PHY (it's normally named by the platform drivers as just "pipe"); - "core" - primary clock of the controller (none of the platform drivers declare such a clock but in accordance with the ref. manual the devices may have it separately specified); - "aux" - auxiliary PMC domain clock (it is named by some platforms as "pcie_aux" and just "aux"); - "ref" - Generic reference clock (it is a generic clock source, which can be used as a signal source for multiple interfaces, some platforms call it as "ref", "general", "pcie_phy", "pcie_phy_ref"). Application resets: - "dbi" - Data-bus interface reset (it's CSR interface clock and is normally called as "apb" though technically it's not APB but DWC PCIe-specific interface); - "mstr" - AXI-bus master reset (some platforms call it as "port", "apps", "bus", "axi_m"); - "slv" - ABI-bus slave reset (some platforms call it as "port", "apps", "bus", "axi_s"). Core resets: - "non-sticky" - non-sticky CSR flags reset; - "sticky" - sticky CSR flags reset; - "pipe" - PIPE-interface (Core-PCS) logic reset (some platforms call it just "pipe"); - "core" - controller primary reset (resets everything except PMC module, some platforms refer to this signal as "soft", "pci"); - "phy" - PCS/PHY block reset (strictly speaking it is normally connected to the input of an external block, but the reference manual says it must be available for the PMC working correctly, some existing platforms call it "pciephy", "phy", "link"); - "hot" - PMC hot reset signal (also called as "sleep"); - "pwr" - cold reset signal (can be referred as "pwr", "turnoff"). Bus reset: - "perst" - PCIe standard signal used to reset the PCIe peripheral devices. As you can see each platform uses it's own naming for basically the same set of the signals. In the framework of this commit we suggest to add a set of the clocks and reset signals resources, corresponding names and identifiers for each denoted entity. At current stage the platforms will be able to use the provided infrastructure to automatically request all these resources and manipulate with them in the Host/EP init callbacks. Alas it isn't that easy to create a common cold/hot reset procedure due to too many platform-specifics in the procedure, like the external flags exposure and the delays requirement. Link: https://lore.kernel.org/r/20221113191301.5526-20-Sergey.Semin@baikalelectronics.ru Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
2022-11-23PCI: dwc: Combine iATU detection proceduresSerge Semin1-29/+10
Since the iATU CSR region is now retrieved in the DW PCIe resources getter there is no much benefits in the iATU detection procedures splitting up. Therefore let's join the iATU unroll/viewport detection procedure with the rest of the iATU parameters detection code. The resultant method will be as coherent as before, while the redundant functions will be eliminated thus producing more readable code. Link: https://lore.kernel.org/r/20221113191301.5526-19-Sergey.Semin@baikalelectronics.ru Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2022-11-23PCI: dwc: Introduce generic resources getterSerge Semin4-53/+65
Currently the DW PCIe Root Port and Endpoint CSR spaces are retrieved in the separate parts of the DW PCIe core driver. It doesn't really make sense since the both controller types have identical set of the core CSR regions: DBI, DBI CS2 and iATU/eDMA. Thus we can simplify the DW PCIe Host and EP initialization methods by moving the platform-specific registers space getting and mapping into a common method. It gets to be even more justified seeing the CSRs base address pointers are preserved in the common DW PCIe descriptor. Note all the OF-based common DW PCIe settings initialization will be moved to the new method too in order to have a single function for all the generic platform properties handling in single place. A nice side-effect of this change is that the pcie-designware-host.c and pcie-designware-ep.c drivers are cleaned up from all the direct dw_pcie storage modification, which makes the DW PCIe core, Root Port and Endpoint modules more coherent. Link: https://lore.kernel.org/r/20221113191301.5526-18-Sergey.Semin@baikalelectronics.ru Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org>
2022-11-23PCI: dwc: Introduce generic controller capabilities interfaceSerge Semin2-6/+17
Since in addition to the already available iATU unrolled mapping we are about to add a few more DW PCIe platform-specific capabilities (CDM-check and generic clocks/resets resources) let's add a generic interface to set and get the flags indicating their availability. The new interface shall improve maintainability of the platform-specific code. Link: https://lore.kernel.org/r/20221113191301.5526-17-Sergey.Semin@baikalelectronics.ru Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2022-11-23PCI: dwc: Introduce dma-ranges property support for RC-hostSerge Semin4-9/+89
In accordance with the generic PCIe Root Port DT-bindings the "dma-ranges" property has the same format as the "ranges" property. The only difference is in their semantics. The "dma-ranges" property describes the PCIe-to-CPU memory mapping in opposite to the CPU-to-PCIe mapping of the "ranges" property. Even though the DW PCIe controllers are normally equipped with the internal Address Translation Unit which inbound and outbound tables can be used to implement both properties semantics, it was surprising for me to discover that the host-related part of the DW PCIe driver currently supports the "ranges" property only while the "dma-ranges" windows are just ignored. Having the "dma-ranges" supported in the driver would be very handy for the platforms, that don't tolerate the 1:1 CPU-PCIe memory mapping and require a customized PCIe memory layout. So let's fix that by introducing the "dma-ranges" property support. First of all we suggest to rename the dw_pcie_prog_inbound_atu() method to dw_pcie_prog_ep_inbound_atu() and create a new version of the dw_pcie_prog_inbound_atu() function. Thus we'll have two methods for the RC and EP controllers respectively in the same way as it has been developed for the outbound ATU setup methods. Secondly aside with the memory window index and type the new dw_pcie_prog_inbound_atu() function will accept CPU address, PCIe address and size as its arguments. These parameters define the PCIe and CPU memory ranges which will be used to setup the respective inbound ATU mapping. The passed parameters need to be verified against the ATU ranges constraints in the same way as it is done for the outbound ranges. Finally the DMA-ranges detected for the PCIe controller need to be converted to the inbound ATU entries during the host controller initialization procedure. It will be done in the framework of the dw_pcie_iatu_setup() method. Note before setting the inbound ranges up we need to disable all the inbound ATU entries in order to prevent unexpected PCIe TLPs translations defined by some third party software like bootloaders. Link: https://lore.kernel.org/r/20221113191301.5526-16-Sergey.Semin@baikalelectronics.ru Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2022-11-22PCI: shpchp: Remove unused get_mode1_ECC_cap callbackIan Cowan3-22/+0
The ->get_mode1_ECC_cap callback in the shpchp_hpc_ops struct is never called, so remove it. [bhelgaas: squash] Link: https://lore.kernel.org/r/20221112142859.319733-2-ian@linux.cowan.aero Link: https://lore.kernel.org/r/20221112142859.319733-3-ian@linux.cowan.aero Link: https://lore.kernel.org/r/20221112142859.319733-4-ian@linux.cowan.aero Signed-off-by: Ian Cowan <ian@linux.cowan.aero> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2022-11-22PCI: acpiphp: Avoid setting is_hotplug_bridge for PCIe Upstream PortsRafael J. Wysocki1-0/+8
It is reported that on some systems pciehp binds to an Upstream Port and attempts to operate it which causes devices below the Port to disappear from the bus. This happens because acpiphp sets dev->is_hotplug_bridge for that Port (after receiving a Device Check notification on it from the platform firmware via ACPI) during the enumeration of PCI devices. get_port_device_capability() sees that dev->is_hotplug_bridge is set and adds PCIE_PORT_SERVICE_HP to Port services, which allows pciehp to bind to the Port in question. Even though this particular problem can be addressed by making the portdrv_core checks more robust, it also causes power management to work differently on the affected systems which generally is not desirable (PCIe Ports with dev->is_hotplug_bridge set have to pass additional tests to be allowed to go into the D3hot/cold power states which affects runtime PM of devices below these Ports). For this reason, amend check_hotplug_bridge() with a PCIe type check to prevent it from setting dev->is_hotplug_bridge for Upstream Ports. Suggested-by: Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/2262230.ElGaqSPkdT@kreacher Reported-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Lukas Wunner <lukas@wunner.de>
2022-11-22PCI/portdrv: Set PCIE_PORT_SERVICE_HP for Root and Downstream Ports onlyRafael J. Wysocki1-0/+2
It is reported that on some systems pciehp binds to an Upstream Port and attempts to operate it which causes devices below the Port to disappear from the bus. This happens because acpiphp sets dev->is_hotplug_bridge for that Port (after receiving a Device Check notification on it from the platform firmware via ACPI) during the enumeration of PCI devices. get_port_device_capability() sees that dev->is_hotplug_bridge is set and adds PCIE_PORT_SERVICE_HP to Port services (which allows pciehp to bind to the Port in question) without consulting the PCIe type, which should be either Root Port or Downstream Port for the hotplug capability to be present. Per PCIe r6.0, sec 7.5.3.2, the Slot Implemented bit is only valid for Downstream Ports (including Root Ports), and PCIe hotplug depends on the Slot Capabilities / Control / Status registers. Make get_port_device_capability() more robust by adding a PCIe type check to it before adding PCIE_PORT_SERVICE_HP to Port services which helps to avoid the problem. [bhelgaas: add spec citation] Suggested-by: Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/4786090.31r3eYUQgx@kreacher Reported-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Lukas Wunner <lukas@wunner.de>
2022-11-21PCI: Check for alloc failure in pci_request_irq()Zeng Heng1-0/+2
When kvasprintf() fails to allocate memory, it returns a NULL pointer. Return error from pci_request_irq() so we don't dereference it. [bhelgaas: commit log] Fixes: 704e8953d3e9 ("PCI/irq: Add pci_request_irq() and pci_free_irq() helpers") Link: https://lore.kernel.org/r/20221121020029.3759444-1-zengheng4@huawei.com Signed-off-by: Zeng Heng <zengheng4@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
2022-11-18treewide: use get_random_u32_below() instead of deprecated functionJason A. Donenfeld1-1/+1
This is a simple mechanical transformation done by: @@ expression E; @@ - prandom_u32_max + get_random_u32_below (E) Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Darrick J. Wong <djwong@kernel.org> # for xfs Reviewed-by: SeongJae Park <sj@kernel.org> # for damon Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> # for infiniband Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> # for arm Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # for mmc Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
2022-11-17PCI: Drop of_match_ptr() to avoid unused variablesBjorn Helgaas2-2/+2
We have stubs for most OF interfaces even when CONFIG_OF is not set, so we allow building of most controller drivers in that case for compile testing. When CONFIG_OF is not set, "of_match_ptr(<match_table>)" compiles to NULL, which leaves <match_table> unused, resulting in errors like this: $ make W=1 drivers/pci/controller/pci-xgene.c:636:34: error: ‘xgene_pcie_match_table’ defined but not used [-Werror=unused-const-variable=] Drop of_match_ptr() to avoid the unused variable warning. See also 1dff012f636d ("PCI: Drop of_match_ptr() to avoid unused variables"). Link: https://lore.kernel.org/r/20221025191339.667614-2-helgaas@kernel.org Link: https://lore.kernel.org/r/20221116205100.1136224-2-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2022-11-17x86/apic: Remove X86_IRQ_ALLOC_CONTIGUOUS_VECTORSThomas Gleixner1-14/+1
Now that the PCI/MSI core code does early checking for multi-MSI support X86_IRQ_ALLOC_CONTIGUOUS_VECTORS is not required anymore. Remove the flag and rely on MSI_FLAG_MULTI_PCI_MSI. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20221111122015.865042356@linutronix.de
2022-11-17PCI/MSI: Remove redundant msi_check() callbackThomas Gleixner1-48/+0
All these sanity checks are now done _before_ any allocation work happens. No point in doing it twice. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20221111122015.749446904@linutronix.de
2022-11-17PCI/MSI: Validate MSI-X contiguous restriction earlyThomas Gleixner1-2/+9
With interrupt domains the sanity check for MSI-X vector validation can be done _before_ any allocation happens. The sanity check only applies to the allocation functions which have an 'entries' array argument. The entries array is filled by the caller with the requested MSI-X indices. Some drivers have gaps in the index space which is not supported on all architectures. The PCI/MSI irq domain has a 'feature' bit to enforce this validation late during the allocation phase. Just do it right away before doing any other work along with the other sanity checks on that array. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20221111122015.691357406@linutronix.de
2022-11-17PCI/MSI: Reject MSI-X earlyThomas Gleixner1-0/+4
Similar to PCI multi-MSI reject MSI-X enablement when a irq domain is attached to the device which does not support MSI-X. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20221111122015.631728309@linutronix.de
2022-11-17PCI/MSI: Reject multi-MSI earlyThomas Gleixner3-0/+35
When hierarchical MSI interrupt domains are enabled then there is no point to do tons of work and detect the missing support for multi-MSI late in the allocation path. Just query the domain feature flags right away. The query function is going to be used for other purposes later and has a mode argument which influences the result: ALLOW_LEGACY returns true when: - there is no irq domain attached (legacy support) - there is a irq domain attached which has the feature flag set DENY_LEGACY returns only true when: - there is a irq domain attached which has the feature flag set This allows to use the function universally without ifdeffery in the calling code. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20221111122015.574339988@linutronix.de
2022-11-17PCI/MSI: Sanitize MSI-X checksThomas Gleixner1-32/+33
There is no point in doing the same sanity checks over and over in a loop during MSI-X enablement. Put them in front of the loop and return early when they fail. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20221111122015.516946468@linutronix.de
2022-11-17PCI/MSI: Reorder functions in msi.cAhmed S. Darwish1-282/+295
There is no way to navigate msi.c without banging the head against the wall every now and then because MSI and MSI-X specific functions are intermingled and the code flow is completely non-obvious. Reorder everthing so common helpers, MSI and MSI-X specific functions are grouped together. Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20221111122015.459089736@linutronix.de
2022-11-17PCI/MSI: Move pci_msi_restore_state() to api.cAhmed S. Darwish3-9/+19
To disentangle the maze in msi.c, all exported device-driver MSI APIs are now to be grouped in one file, api.c. Move pci_msi_enabled() and add kernel-doc for the function. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20221111122015.331584998@linutronix.de
2022-11-17PCI/MSI: Move pci_msi_enabled() to api.cAhmed S. Darwish3-13/+16
To disentangle the maze in msi.c, all exported device-driver MSI APIs are now to be grouped in one file, api.c. Move pci_msi_enabled() and make its kernel-doc comprehensive. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20221111122015.271447896@linutronix.de
2022-11-17PCI/MSI: Move pci_irq_get_affinity() to api.cAhmed S. Darwish2-38/+43
To disentangle the maze in msi.c, all exported device-driver MSI APIs are now to be grouped in one file, api.c. Move pci_irq_get_affinity() and let its kernel-doc match rest of the file. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20221111122015.214792769@linutronix.de
2022-11-17PCI/MSI: Move pci_disable_msix() to api.cAhmed S. Darwish3-13/+26
To disentangle the maze in msi.c, all exported device-driver MSI APIs are now to be grouped in one file, api.c. Move pci_disable_msix() and make its kernel-doc comprehensive. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20221111122015.156785224@linutronix.de
2022-11-17PCI/MSI: Move pci_msix_vec_count() to api.cAhmed S. Darwish2-20/+20
To disentangle the maze in msi.c, all exported device-driver MSI APIs are now to be grouped in one file, api.c. Move pci_msix_vec_count() and make its kernel-doc comprehensive. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20221111122015.099461602@linutronix.de
2022-11-17PCI/MSI: Move pci_free_irq_vectors() to api.cAhmed S. Darwish2-13/+15
To disentangle the maze in msi.c, all exported device-driver MSI APIs are now to be grouped in one file, api.c. Move pci_free_irq_vectors() and make its kernel-doc comprehensive. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20221111122015.042870570@linutronix.de
2022-11-17PCI/MSI: Move pci_irq_vector() to api.cAhmed S. Darwish2-24/+23
To disentangle the maze in msi.c, all exported device-driver MSI APIs are now to be grouped in one file, api.c. Move pci_irq_vector() and let its kernel-doc match the rest of the file. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20221111122014.984490384@linutronix.de
2022-11-17PCI/MSI: Move pci_alloc_irq_vectors_affinity() to api.cAhmed S. Darwish2-65/+59
To disentangle the maze in msi.c, all exported device-driver MSI APIs are now to be grouped in one file, api.c. Move pci_alloc_irq_vectors_affinity() and let its kernel-doc reference pci_alloc_irq_vectors() documentation added in parent commit. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20221111122014.927531290@linutronix.de
2022-11-17PCI/MSI: Move pci_alloc_irq_vectors() to api.cAhmed S. Darwish1-0/+33
To disentangle the maze in msi.c, all exported device-driver MSI APIs are now to be grouped in one file, api.c. Make pci_alloc_irq_vectors() a real function instead of wrapper and add proper kernel doc to it. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20221111122014.870888193@linutronix.de
2022-11-17PCI/MSI: Move pci_enable_msix_range() to api.cAhmed S. Darwish3-26/+39
To disentangle the maze in msi.c, all exported device-driver MSI APIs are now to be grouped in one file, api.c. Move pci_enable_msix_range() and make its kernel-doc comprehensive. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20221111122014.813792885@linutronix.de
2022-11-17PCI/MSI: Move pci_enable_msi() API to api.cAhmed S. Darwish3-12/+26
To disentangle the maze in msi.c all exported device-driver MSI APIs are now to be grouped in one file, api.c. Move pci_enable_msi() and make its kernel-doc comprehensive. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20221111122014.755178149@linutronix.de
2022-11-17PCI/MSI: Move pci_disable_msi() to api.cAhmed S. Darwish4-19/+47
msi.c is a maze of randomly sorted functions which makes the code unreadable. As a first step split the driver visible API and the internal implementation which also allows proper API documentation via one file. Create drivers/pci/msi/api.c to group all exported device-driver PCI/MSI APIs in one C file. Begin by moving pci_disable_msi() there and add kernel-doc for the function as appropriate. Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20221111122014.696798036@linutronix.de
2022-11-17PCI/MSI: Move mask and unmask helpers to msi.hAhmed S. Darwish2-70/+74
The upcoming support for per device MSI interrupt domains needs to share some of the inline helpers with the MSI implementation. Move them to the header file. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20221111122014.640052354@linutronix.de
2022-11-17PCI/MSI: Get rid of externs in msi.hAhmed S. Darwish1-4/+4
Follow the style of <linux/pci.h> Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20221111122014.582175082@linutronix.de
2022-11-17genirq: Get rid of GENERIC_MSI_IRQ_DOMAINThomas Gleixner1-1/+0
Adjust to reality and remove another layer of pointless Kconfig indirection. CONFIG_GENERIC_MSI_IRQ is good enough to serve all purposes. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20221111122014.524842979@linutronix.de
2022-11-17PCI/MSI: Get rid of PCI_MSI_IRQ_DOMAINThomas Gleixner6-52/+44
What a zoo: PCI_MSI select GENERIC_MSI_IRQ PCI_MSI_IRQ_DOMAIN def_bool y depends on PCI_MSI select GENERIC_MSI_IRQ_DOMAIN Ergo PCI_MSI enables PCI_MSI_IRQ_DOMAIN which in turn selects GENERIC_MSI_IRQ_DOMAIN. So all the dependencies on PCI_MSI_IRQ_DOMAIN are just an indirection to PCI_MSI. Match the reality and just admit that PCI_MSI requires GENERIC_MSI_IRQ_DOMAIN. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20221111122014.467556921@linutronix.de
2022-11-17PCI/MSI: Let the MSI core free descriptorsAhmed S. Darwish1-3/+7
Let the core do the freeing of descriptors and just keep it around for the legacy case. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20221111122014.409654736@linutronix.de
2022-11-17PCI/MSI: Use msi_domain_info:: Bus_tokenAhmed S. Darwish1-8/+3
Set the bus token in the msi_domain_info structure and let the core code handle the update. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20221111122014.352437595@linutronix.de
2022-11-17PCI/MSI: Check for MSI enabled in __pci_msix_enable()Thomas Gleixner1-0/+5
PCI/MSI and PCI/MSI-X are mutually exclusive, but the MSI-X enable code lacks a check for already enabled MSI. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ashok Raj <ashok.raj@intel.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20221111122013.653556720@linutronix.de
2022-11-16PCI/DOE: Fix maximum data object length miscalculationLi Ming1-4/+16
Per PCIe r6.0, sec 6.30.1, a data object Length of 0x0 indicates 2^18 DWORDs (256K DW or 1MB) being transferred. Adjust the value of data object length for this case on both sending side and receiving side. Don't bother checking whether Length is greater than SZ_1M because all values of the 18-bit Length field are valid, and it is impossible to represent anything larger than SZ_1M: 0x00000 256K DW (1M bytes) 0x00001 1 DW (4 bytes) ... 0x3ffff 256K-1 DW (1M - 4 bytes) [bhelgaas: commit log] Link: https://lore.kernel.org/r/20221116015637.3299664-1-ming4.li@intel.com Fixes: 9d24322e887b ("PCI/DOE: Add DOE mailbox support functions") Signed-off-by: Li Ming <ming4.li@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Lukas Wunner <lukas@wunner.de> Cc: stable@vger.kernel.org # v6.0+
2022-11-15PCI: pciehp: Enable by default if USB4 enabledAlbert Zhou2-2/+9
Thunderbolt/USB4 PCIe tunneling depends on native PCIe hotplug. Enable pciehp by default if USB4 is enabled. [bhelgaas: squash, update subject, commit logs, tidy whitespace] Link: https://lore.kernel.org/r/20221115113857.35800-2-albert.zhou.50@gmail.com Link: https://lore.kernel.org/r/20221115113857.35800-3-albert.zhou.50@gmail.com Signed-off-by: Albert Zhou <albert.zhou.50@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-26 04:26:41 +0000