summaryrefslogtreecommitdiff
path: root/drivers/pci
AgeCommit message (Collapse)Author
2025-01-16PCI: imx6: Add missing reference clock disable logicRichard Zhu
Ensure the *_enable_ref_clk() function is symmetric by addressing missing disable parts on some platforms. Fixes: d0a75c791f98 ("PCI: imx6: Factor out ref clock disable to match enable") Link: https://lore.kernel.org/r/20241126075702.4099164-7-hongxing.zhu@nxp.com Signed-off-by: Richard Zhu <hongxing.zhu@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: Frank Li <Frank.Li@nxp.com>
2025-01-16PCI: imx6: Deassert apps_reset in imx_pcie_deassert_core_reset()Richard Zhu
Since the apps_reset is asserted in imx_pcie_assert_core_reset(), it should be deasserted in imx_pcie_deassert_core_reset(). Fixes: 9b3fe6796d7c ("PCI: imx6: Add code to support i.MX7D") Link: https://lore.kernel.org/r/20241126075702.4099164-6-hongxing.zhu@nxp.com Signed-off-by: Richard Zhu <hongxing.zhu@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: Frank Li <Frank.Li@nxp.com>
2025-01-16PCI: imx6: Skip controller_id generation logic for i.MX7DRichard Zhu
The i.MX7D only has one PCIe controller, so controller_id should always be 0. The previous code is incorrect although yielding the correct result. Fix by removing "IMX7D" from the switch case branch. Fixes: 2d8ed461dbc9 ("PCI: imx6: Add support for i.MX8MQ") Link: https://lore.kernel.org/r/20241126075702.4099164-5-hongxing.zhu@nxp.com Signed-off-by: Richard Zhu <hongxing.zhu@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: Frank Li <Frank.Li@nxp.com>
2025-01-16PCI: imx6: Fetch dbi2 and iATU base addesses from DTRichard Zhu
Since dw_pcie_get_resources() gets the dbi2 and iATU base addresses from DT, remove the code from the imx6 driver that does the same. Upstream DTSes have not enabled Endpoint function. So nothing is broken for old upstream DTBs. Link: https://lore.kernel.org/r/20241126075702.4099164-4-hongxing.zhu@nxp.com Signed-off-by: Richard Zhu <hongxing.zhu@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>
2025-01-16PCI: imx6: Configure PHY based on Root Complex or Endpoint modeFrank Li
Pass PHY_MODE_PCIE_EP if the PCI controller operates in Endpoint (EP) mode, and fix the Root Complex (RC) mode being hardcoded using a drvdata mode check. Fixes: 8026f2d8e8a9 ("PCI: imx6: Call common PHY API to set mode, speed, and submode") Link: https://lore.kernel.org/r/20241119-pci_fixup_addr-v8-6-c4bfa5193288@nxp.com Signed-off-by: Frank Li <Frank.Li@nxp.com> [kwilczynski: commit log] 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: Richard Zhu <hongxing.zhu@nxp.com>
2025-01-16PCI: imx6: Add Refclk for i.MX95 PCIeRichard Zhu
Add "ref" clock to enable Refclk. To avoid breaking DT backwards compatibility, the i.MX95 "ref" clock is optional. Use devm_clk_get_optional() to fetch i.MX95 PCIe optional clocks in driver. If using external clock, "ref" clock should point to external reference. If using internal clock, CREF_EN in LAST_TO_REG controls reference output, implemented in drivers/clk/imx/clk-imx95-blk-ctl.c. Link: https://lore.kernel.org/r/20241126075702.4099164-3-hongxing.zhu@nxp.com Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Frank Li <Frank.Li@nxp.com>
2025-01-16PCI: imx6: Add i.MX8Q PCIe Endpoint (EP) supportFrank Li
Add support for the i.MX8Q series (i.MX8QM, i.MX8QXP, and i.MX8DXL) PCIe Endpoint (EP). On the i.MX8Q platforms, the PCI bus addresses differ from the CPU addresses. However, the DesignWare (DWC) driver already handles this in the common code. Link: https://lore.kernel.org/r/20241119-pci_fixup_addr-v8-7-c4bfa5193288@nxp.com Signed-off-by: Frank Li <Frank.Li@nxp.com> [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Richard Zhu <hongxing.zhu@nxp.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2025-01-16PCI: Add pcie_print_tlp_log() to print TLP Header and Prefix LogIlpo Järvinen
Add pcie_print_tlp_log() to print TLP Header and Prefix Log. Print End-End Prefixes only if they are non-zero. Consolidate the few places which currently print TLP using custom formatting. Link: https://lore.kernel.org/r/20250114170840.1633-9-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-01-16PCI: Add TLP Prefix reading to pcie_read_tlp_log()Ilpo Järvinen
pcie_read_tlp_log() handles only 4 Header Log DWORDs but TLP Prefix Log (PCIe r6.1 secs 7.8.4.12 & 7.9.14.13) may also be present. Generalize pcie_read_tlp_log() and struct pcie_tlp_log to also handle TLP Prefix Log. The relevant registers are formatted identically in AER and DPC Capability, but has these variations: a) The offsets of TLP Prefix Log registers vary. b) DPC RP PIO TLP Prefix Log register can be < 4 DWORDs. c) AER TLP Prefix Log Present (PCIe r6.1 sec 7.8.4.7) can indicate Prefix Log is not present. Therefore callers must pass the offset of the TLP Prefix Log register and the entire length to pcie_read_tlp_log() to be able to read the correct number of TLP Prefix DWORDs from the correct offset. Link: https://lore.kernel.org/r/20250114170840.1633-8-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> [bhelgaas: squash ternary fix from https://lore.kernel.org/r/20250116172019.88116-1-colin.i.king@gmail.com] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-01-15PCI: of: Simplify devm_of_pci_get_host_bridge_resources() interfaceBjorn Helgaas
Previously pci_parse_request_of_pci_ranges() supplied the default bus range to devm_of_pci_get_host_bridge_resources(), but that function is static and has no other callers, so there's no reason to complicate its interface by passing the default bus range. Drop the busno and bus_max parameters and use 0x0 and 0xff directly in devm_of_pci_get_host_bridge_resources(). Link: https://lore.kernel.org/r/20250113231557.441289-4-helgaas@kernel.org [bhelgaas: dev_warn() for invalid end of bus-range] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2025-01-15PCI: of: Drop 'No bus range found' messageBjorn Helgaas
The typical bus range for a host bridge is [bus 00-ff], and devm_of_pci_get_host_bridge_resources() defaults to that unless DT contains a "bus-range" property. devm_of_pci_get_host_bridge_resources() previously emitted a message when there was no "bus-range" property, but that seems unnecessary for this common situation. Remove the message. Link: https://lore.kernel.org/r/20250113231557.441289-3-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
2025-01-15PCI: Unexport of_pci_parse_bus_range()Bjorn Helgaas
of_pci_parse_bus_range() is only used in drivers/pci/of.c, so make it static and unexport it. Link: https://lore.kernel.org/r/20250113231557.441289-2-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
2025-01-15PCI: apple: Convert to {en,dis}able_device() callbacksMarc Zyngier
Now that the core host-bridge infrastructure is able to give us a callback on each device being added or removed, convert the bus-notifier hack to it. Link: https://lore.kernel.org/r/20241204150145.800408-3-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2025-01-15PCI: host-generic: Allow {en,dis}able_device() to be provided via pci_ecam_opsMarc Zyngier
In order to let host controller drivers using the host-generic infrastructure use the {en,dis}able_device() callbacks that can be used to configure sideband RID mapping hardware, provide these two callbacks as part of the pci_ecam_ops structure. Link: https://lore.kernel.org/r/20241204150145.800408-2-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2025-01-15PCI: imx6: Add IOMMU and ITS MSI support for i.MX95Frank Li
For the i.MX95, the configuration of a LUT is necessary to convert PCIe Requester IDs (RIDs) to StreamIDs, which are used by both IOMMU and ITS. This involves checking msi-map and iommu-map device tree properties to ensure consistent mapping of Requester IDs to the same StreamIDs. Subsequently, LUT-related registers are configured. If a msi-map isn't detected, the platform relies on DWC built-in controller for MSIs that do not need StreamIDs. Implement PCI bus callback function to handle enable_device() and disable_device() operations, setting up the LUT whenever a new PCI device is enabled. Known limitations: - If iommu-map exists in the device tree but the IOMMU controller is disabled, StreamIDs are programmed into the LUT. However, if a RID is out of range of the iommu-map, enabling the PCI device would result in a failure, although the PCI device can work without the IOMMU. - If msi-map exists in the device tree but the MSI controller is disabled, MSIs will not work. The DWC driver skips initializing the built-in MSI controller, falling back to legacy PCI INTx only. Link: https://lore.kernel.org/r/20250114-imx95_lut-v9-2-39f58dbed03a@nxp.com Signed-off-by: Frank Li <Frank.Li@nxp.com> [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> [bhelgaas: fix uninitialized "sid" in imx_pcie_enable_device()] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Richard Zhu <hongxing.zhu@nxp.com>
2025-01-15x86/apic: Convert to IRQCHIP_MOVE_DEFERREDThomas Gleixner
Instead of marking individual interrupts as safe to be migrated in arbitrary contexts, mark the interrupt chips, which require the interrupt to be moved in actual interrupt context, with the new IRQCHIP_MOVE_DEFERRED flag. This makes more sense because this is a per interrupt chip property and not restricted to individual interrupts. That flips the logic from the historical opt-out to a opt-in model. This is simpler to handle for other architectures, which default to unrestricted affinity setting. It also allows to cleanup the redundant core logic significantly. All interrupt chips, which belong to a top-level domain sitting directly on top of the x86 vector domain are marked accordingly, unless the related setup code marks the interrupts with IRQ_MOVE_PCNTXT, i.e. XEN. No functional change intended. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Steve Wahl <steve.wahl@hpe.com> Acked-by: Wei Liu <wei.liu@kernel.org> Link: https://lore.kernel.org/all/20241210103335.563277044@linutronix.de
2025-01-15PCI: rockchip-ep: Fix error code in rockchip_pcie_ep_init_ob_mem()Dan Carpenter
Return -ENOMEM if pci_epc_mem_alloc_addr() fails. Don't return success. Link: https://lore.kernel.org/r/Z014ylYz_xrrgI4W@stanley.mountain Fixes: 945648019466 ("PCI: rockchip-ep: Refactor rockchip_pcie_ep_probe() memory allocations") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Niklas Cassel <cassel@kernel.org>
2025-01-15PCI: rockchip: Refactor rockchip_pcie_disable_clocks() signatureAnand Moon
Refactor rockchip_pcie_disable_clocks() to accept a struct rockchip_pcie pointer instead of a void pointer thus improving type safety and code readability by explicitly specifying the expected data type. Link: https://lore.kernel.org/r/20241202151150.7393-4-linux.amoon@gmail.com Signed-off-by: Anand Moon <linux.amoon@gmail.com> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2025-01-15PCI: rockchip: Simplify reset control handling by using ↵Anand Moon
reset_control_bulk*() function Currently, the driver acquires and asserts/deasserts the resets individually thereby making the driver complex to read. This can be simplified by using the reset_control_bulk() APIs. Use devm_reset_control_bulk_get_exclusive() API to acquire all the resets and use reset_control_bulk_{assert/deassert}() APIs to assert/deassert them in bulk. Following the recommendations in 'Rockchip RK3399 TRM v1.3 Part2': 1. Split the reset controls into two groups as per section '17.5.8.1.1 PCIe as Root Complex'. 2. Deassert the 'Pipe, MGMT Sticky, MGMT, Core' resets in groups as per section '17.5.8.1.1 PCIe as Root Complex'. This is accomplished using the reset_control_bulk APIs. Link: https://lore.kernel.org/r/20241202151150.7393-3-linux.amoon@gmail.com Co-developed-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Anand Moon <linux.amoon@gmail.com> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> [kwilczynski: squash error handling fix from https://lore.kernel.org/r/7da6ac56-af55-4436-9597-6af24df8122c@stanley.mountain] Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2025-01-15PCI: Add enable_device() and disable_device() callbacks for bridgesFrank Li
Some PCI host bridges require special handling when enabling or disabling PCI devices. For example, the i.MX95 platform has a lookup table to map Requester IDs to StreamIDs, which the SMMU and MSI controller use to identify the source of DMA accesses. Without this mapping, DMA accesses may target unintended memory, which would corrupt memory or read the wrong data. Add a host bridge enable_device() hook the imx6 driver can use to configure the Requester ID to StreamID mapping. The hardware table isn't big enough to map all possible Requester IDs, so this hook may fail if no table space is available. In that case, return failure from pci_enable_device(). It might make more sense to make pci_set_master() decline to enable bus mastering and return failure, but it currently doesn't have a way to return failure. Link: https://lore.kernel.org/r/20250114-imx95_lut-v9-1-39f58dbed03a@nxp.com Tested-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Marc Zyngier <maz@kernel.org> Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2025-01-15PCI/DPC: Quirk PIO log size for Intel Raptor Lake-PTakashi Iwai
Apparently the Raptor Lake-P reference firmware configures the PIO log size correctly, but some vendor BIOSes, including at least ASUSTeK COMPUTER INC. Zenbook UX3402VA_UX3402VA, do not. Apply the quirk for Raptor Lake-P. This prevents kernel complaints like: DPC: RP PIO log size 0 is invalid and also enables the DPC driver to dump the RP PIO Log registers when DPC is triggered. Note that the bug report also mentions 8086:a76e, which has been already added by 627c6db20703 ("PCI/DPC: Quirk PIO log size for Intel Raptor Lake Root Ports"). Link: https://lore.kernel.org/r/20250102164315.7562-1-tiwai@suse.de Link: https://bugzilla.suse.com/show_bug.cgi?id=1234623 Signed-off-by: Takashi Iwai <tiwai@suse.de> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
2025-01-15PCI/sysfs: Remove unnecessary zero in initializerIlpo Järvinen
Providing empty initializer for an array is enough to set its elements to zero. Thus, remove the redundant 0 from the initializer. Link: https://lore.kernel.org/r/20241028174046.1736-4-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
2025-01-15PCI/sysfs: Use __free() in reset_method_store()Ilpo Järvinen
Use __free() from cleanup.h to handle freeing options in reset_method_store() as it simplifies the code flow. Link: https://lore.kernel.org/r/20241028174046.1736-3-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
2025-01-15PCI/sysfs: Move reset related sysfs code to correct fileIlpo Järvinen
Most PCI sysfs code and structs are in a dedicated file but a few reset related things remain in pci.c. Move also them to pci-sysfs.c and drop pci_dev_reset_method_attr_is_visible() as it is 100% duplicate of pci_dev_reset_attr_is_visible(). Link: https://lore.kernel.org/r/20241028174046.1736-2-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
2025-01-14PCI: Store number of supported End-End TLP PrefixesIlpo Järvinen
eetlp_prefix_path in the struct pci_dev tells if End-End TLP Prefixes are supported by the path or not, and the value is only calculated if CONFIG_PCI_PASID is set. The Max End-End TLP Prefixes field in the Device Capabilities Register 2 also tells how many (1-4) End-End TLP Prefixes are supported (PCIe r6.2 sec 7.5.3.15). The number of supported End-End Prefixes is useful for reading correct number of DWORDs from TLP Prefix Log register in AER capability (PCIe r6.2 sec 7.8.4.12). Replace eetlp_prefix_path with eetlp_prefix_max and determine the number of supported End-End Prefixes regardless of CONFIG_PCI_PASID so that an upcoming commit generalizing TLP Prefix Log register reading does not have to read extra DWORDs for End-End Prefixes that never will be there. The value stored into eetlp_prefix_max is directly derived from device's Max End-End TLP Prefixes and does not consider limitations imposed by bridges or the Root Port beyond supported/not supported flags. This is intentional for two reasons: 1) PCIe r6.2 spec sections 2.2.10.4 & 6.2.4.4 indicate that a TLP is malformed only if the number of prefixes exceed the number of Max End-End TLP Prefixes, which seems to be the case even if the device could never receive that many prefixes due to smaller maximum imposed by a bridge or the Root Port. If TLP parsing is later added, this distinction is significant in interpreting what is logged by the TLP Prefix Log registers and the value matching to the Malformed TLP threshold is going to be more useful. 2) TLP Prefix handling happens autonomously on a low layer and the value in eetlp_prefix_max is not programmed anywhere by the kernel (i.e., there is no limiter OS can control to prevent sending more than N TLP Prefixes). Link: https://lore.kernel.org/r/20250114170840.1633-7-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com>
2025-01-14PCI: Use unsigned int i in pcie_read_tlp_log()Ilpo Järvinen
Loop variable i counting from 0 upwards does not need to be signed so make it unsigned int. Link: https://lore.kernel.org/r/20250114170840.1633-6-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-01-14PCI: Use same names in pcie_read_tlp_log() prototype and definitionIlpo Järvinen
pcie_read_tlp_log()'s prototype and function signature diverged due to changes made while applying. Make the parameters of pcie_read_tlp_log() named identically. Link: https://lore.kernel.org/r/20250114170840.1633-5-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com>
2025-01-14PCI: Add defines for TLP Header/Prefix log sizesIlpo Järvinen
Add defines for AER and DPC capabilities TLP Header Logging register sizes (PCIe r6.2, sec 7.8.4 / 7.9.14) and replace literals with them. Link: https://lore.kernel.org/r/20250114170840.1633-4-ilpo.jarvinen@linux.intel.com Suggested-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2025-01-14PCI: Move TLP Log handling to its own fileIlpo Järvinen
TLP Log is a PCIe feature and is processed only by AER and DPC. Configwise, DPC depends AER being enabled. In lack of better place, the TLP Log handling code was initially placed into pci.c but it can be easily placed in a separate file. Move TLP Log handling code to its own file under pcie/ subdirectory and include it only when AER is enabled. Link: https://lore.kernel.org/r/20250114170840.1633-3-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com>
2025-01-14PCI: Don't expose pcie_read_tlp_log() outside PCI subsystemIlpo Järvinen
pcie_read_tlp_log() was exposed by the commit 0a5a46a6a61b ("PCI/AER: Generalize TLP Header Log reading") with the intent that drivers could use it, but the PCI maintainer later decided that drivers should be encouraged to use PCI core diagnostic logging of generic AER registers rather than building their own. Drivers that currently implement their own diagnostic logging include ixgbe (ixgbe_io_error_detected()) and iwlwifi (iwl_trans_pcie_dump_regs()). Remove the unwanted EXPORT of pcie_read_tlp_log() and remove it from include/linux/aer.h. Link: https://lore.kernel.org/r/20250114170840.1633-2-ilpo.jarvinen@linux.intel.com Link: https://lore.kernel.org/all/20240322193011.GA701027@bhelgaas/ Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com>
2025-01-14Merge tag 'pci-v6.13-fixes-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci Pull pci fix from Bjorn Helgaas: - Prevent bwctrl NULL pointer dereference that caused hangs on shutdown on ASUS ROG Strix SCAR 17 G733PYV (Lukas Wunner) * tag 'pci-v6.13-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: PCI/bwctrl: Fix NULL pointer deref on unbind and bind
2025-01-14PCI: mvebu: Enable module autoloadingLiao Chen
Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded based on the alias from of_device_id table. Link: https://lore.kernel.org/r/20240903132311.961646-1-liaochen4@huawei.com Signed-off-by: Liao Chen <liaochen4@huawei.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
2025-01-13PCI: rockchip: Simplify clock handling by using clk_bulk*() functionsAnand Moon
Currently, the driver acquires clocks and prepare/enable/disable/unprepare the clocks individually thereby making the driver complex to read. The driver can be simplified by using the clk_bulk*() APIs. Use: - devm_clk_bulk_get_all() API to acquire all the clocks - clk_bulk_prepare_enable() to prepare/enable clocks - clk_bulk_disable_unprepare() APIs to disable/unprepare them in bulk Link: https://lore.kernel.org/r/20241202151150.7393-2-linux.amoon@gmail.com Signed-off-by: Anand Moon <linux.amoon@gmail.com> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> [bhelgaas: squash error handling fix from https://lore.kernel.org/r/20250106153041.55267-1-linux.amoon@gmail.com] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2025-01-13PCI: rockchip: Add missing fields descriptions for struct rockchip_pcie_epDamien Le Moal
When compiling the Rockchip endpoint driver with -W=1, the following warnings can be seen in the output: drivers/pci/controller/pcie-rockchip-ep.c:59: warning: Function parameter or struct member 'perst_irq' not described in 'rockchip_pcie_ep' drivers/pci/controller/pcie-rockchip-ep.c:59: warning: Function parameter or struct member 'perst_asserted' not described in 'rockchip_pcie_ep' drivers/pci/controller/pcie-rockchip-ep.c:59: warning: Function parameter or struct member 'link_up' not described in 'rockchip_pcie_ep' drivers/pci/controller/pcie-rockchip-ep.c:59: warning: Function parameter or struct member 'link_training' not described in 'rockchip_pcie_ep' Fix these warnings by adding the missing field descriptions in struct rockchip_pcie_ep kernel-doc comment. Fixes: a7137cbf6bd5 ("PCI: rockchip-ep: Handle PERST# signal in EP mode") Fixes: bd6e61df4b2e ("PCI: rockchip-ep: Improve link training") Link: https://lore.kernel.org/r/20241216133404.540736-1-dlemoal@kernel.org Reported-by: Bjorn Helgaas <helgaas@kernel.org> Signed-off-by: Damien Le Moal <dlemoal@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>
2025-01-13PCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region()King Dix
The rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region() macro to request a needed resource. A string variable that lives on the stack is then used to store a dynamically computed resource name, which is then passed on as one of the macro arguments. This can lead to undefined behavior. Depending on the current contents of the memory, the manifestations of errors may vary. One possible output may be as follows: $ cat /proc/iomem 30000000-37ffffff : 38000000-3fffffff : Sometimes, garbage may appear after the colon. In very rare cases, if no NULL-terminator is found in memory, the system might crash because the string iterator will overrun which can lead to access of unmapped memory above the stack. Thus, fix this by replacing outbound_name with the name of the previously requested resource. With the changes applied, the output will be as follows: $ cat /proc/iomem 30000000-37ffffff : memory2 38000000-3fffffff : memory3 Fixes: 2a6d0d63d999 ("PCI: rcar: Add endpoint mode support") Link: https://lore.kernel.org/r/tencent_DBDCC19D60F361119E76919ADAB25EC13C06@qq.com Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: King Dix <kingdix10@qq.com> [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2025-01-13PCI: mediatek-gen3: Enable async probe by defaultDouglas Anderson
The mediatek-gen3 driver can run its probe routine fairly slow on some hardware, which adds to the total time it takes for the system start up. Thus, turn on async mode for the probe to avoid blocking the rest of the system. Link: https://lore.kernel.org/r/20241220145205.1.Ibf2563896c3b1fc133bb46d3fc96ad0041763922@changeid Signed-off-by: Douglas Anderson <dianders@chromium.org> [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2025-01-13PCI: mediatek-gen3: Avoid PCIe resetting via PERST# for Airoha EN7581 SoCLorenzo Bianconi
Airoha EN7581 has a hw bug asserting/releasing PERST# signal causing occasional PCIe link down issues. In order to overcome the problem, PERST# signal is not asserted/released during device probe or suspend/resume phase and the PCIe block is reset using en7523_reset_assert() and en7581_pci_enable(). Introduce flags field in the mtk_gen3_pcie_pdata struct in order to specify per-SoC capabilities. Link: https://lore.kernel.org/r/20250109-pcie-en7581-rst-fix-v4-1-4a45c89fb143@kernel.org Tested-by: Hui Ma <hui.ma@airoha.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
2025-01-13PCI: mediatek-gen3: Rely on msleep() in mtk_pcie_en7581_power_up()Lorenzo Bianconi
Since mtk_pcie_en7581_power_up() runs in non-atomic context, rely on msleep() routine instead of mdelay(). Link: https://lore.kernel.org/r/20250108-pcie-en7581-fixes-v6-5-21ac939a3b9b@kernel.org Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2025-01-13PCI: mediatek-gen3: Move reset delay in mtk_pcie_en7581_power_up()Lorenzo Bianconi
Airoha EN7581 has a hw bug asserting/releasing PCIE_PE_RSTB signal causing occasional PCIe link down issues. In order to overcome the problem, PCIe block is reset using REG_PCI_CONTROL (0x88) and REG_RESET_CONTROL (0x834) registers available in the clock module running clk_bulk_prepare_enable() in mtk_pcie_en7581_power_up(). In order to make the code more readable, move the wait for the time needed to complete the PCIe reset from en7581_pci_enable() to mtk_pcie_en7581_power_up(). Reduce reset timeout from 250ms to the standard PCIE_T_PVPERL_MS value (100ms) since it has no impact on the driver behavior. Link: https://lore.kernel.org/r/20250108-pcie-en7581-fixes-v6-4-21ac939a3b9b@kernel.org Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Acked-by: Stephen Boyd <sboyd@kernel.org>
2025-01-13PCI: mediatek-gen3: Add comment about initialization order in ↵Lorenzo Bianconi
mtk_pcie_en7581_power_up() Add a comment in mtk_pcie_en7581_power_up() to clarify, unlike the other MediaTek Gen3 controllers, the Airoha EN7581 requires PHY initialization and power-on before PHY reset deassert. Link: https://lore.kernel.org/r/20250108-pcie-en7581-fixes-v6-3-21ac939a3b9b@kernel.org Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2025-01-13PCI: mediatek-gen3: Move reset/assert callbacks in .power_up()Lorenzo Bianconi
In order to make the code more readable, the reset_control_bulk_assert() function for PHY reset lines is moved to make it pair with reset_control_bulk_deassert() in mtk_pcie_power_up() and mtk_pcie_en7581_power_up(). The same change is done for reset_control_assert() used to assert MAC reset line. Introduce PCIE_MTK_RESET_TIME_US macro for the time needed to complete PCIe reset on MediaTek controller. Link: https://lore.kernel.org/r/20250108-pcie-en7581-fixes-v6-2-21ac939a3b9b@kernel.org Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2025-01-13PCI: mediatek-gen3: Rely on clk_bulk_prepare_enable() in ↵Lorenzo Bianconi
mtk_pcie_en7581_power_up() Replace clk_bulk_prepare() and clk_bulk_enable() with clk_bulk_prepare_enable() in mtk_pcie_en7581_power_up() routine. Link: https://lore.kernel.org/r/20250108-pcie-en7581-fixes-v6-1-21ac939a3b9b@kernel.org Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2025-01-07PCI/bwctrl: Fix NULL pointer deref on unbind and bindLukas Wunner
The interrupt handler for bandwidth notifications, pcie_bwnotif_irq(), dereferences a "data" pointer. On unbind, that pointer is set to NULL by pcie_bwnotif_remove(). However the interrupt handler may still be invoked afterwards and will dereference that NULL pointer. That's because the interrupt is requested using a devm_*() helper and the driver core releases devm_*() resources *after* calling ->remove(). pcie_bwnotif_remove() does clear the Link Bandwidth Management Interrupt Enable and Link Autonomous Bandwidth Interrupt Enable bits in the Link Control Register, but that won't prevent execution of pcie_bwnotif_irq(): The interrupt for bandwidth notifications may be shared with AER, DPC, PME, and hotplug. So pcie_bwnotif_irq() may be executed as long as the interrupt is requested. There's a similar race on bind: pcie_bwnotif_probe() requests the interrupt when the "data" pointer still points to NULL. A NULL pointer deref may thus likewise occur if AER, DPC, PME or hotplug raise an interrupt in-between the bandwidth controller's call to devm_request_irq() and assignment of the "data" pointer. Drop the devm_*() usage and reorder requesting of the interrupt to fix the issue. While at it, drop a stray but harmless no_free_ptr() invocation when assigning the "data" pointer in pcie_bwnotif_probe(). Ilpo points out that the locking on unbind and bind needs to be symmetric, so move the call to pcie_bwnotif_disable() inside the critical section protected by pcie_bwctrl_setspeed_rwsem and pcie_bwctrl_lbms_rwsem. Evert reports a hang on shutdown of an ASUS ROG Strix SCAR 17 G733PYV. The issue is no longer reproducible with the present commit. Evert found that attaching a USB-C monitor prevented the hang. The machine contains an ASMedia USB 3.2 controller below a hotplug-capable Root Port. So one possible explanation is that the controller gets hot-removed on shutdown unless something is connected. And the ensuing hotplug interrupt occurs exactly when the bandwidth controller is unregistering. The precise cause could not be determined because the screen had already turned black when the hang occurred. Link: https://lore.kernel.org/r/ae2b02c9cfbefff475b6e132b0aa962aaccbd7b2.1736162539.git.lukas@wunner.de Fixes: 665745f27487 ("PCI/bwctrl: Re-add BW notification portdrv as PCIe BW controller") Reported-by: Evert Vorster <evorster@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219629 Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Evert Vorster <evorster@gmail.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-12-29Merge tag 'irq-urgent-2024-12-29' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq fix from Ingo Molnar: "Fix bogus MSI IRQ setup warning on RISC-V" * tag 'irq-urgent-2024-12-29' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: PCI/MSI: Handle lack of irqdomain gracefully
2024-12-23PCI: exynos: Switch to devm_clk_bulk_get_all_enabled()Cristian Ciocaltea
The helper devm_clk_bulk_get_all_enable() missed to return the number of clocks stored in the clk_bulk_data table referenced by the clks argument and, therefore, will be dropped. Use the newly introduced devm_clk_bulk_get_all_enabled() variant instead, which is consistent with devm_clk_bulk_get_all() in terms of the returned value: > 0 if one or more clocks have been stored = 0 if there are no clocks < 0 if an error occurred Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20241217-clk_bulk_ena_fix-v5-2-aafbbb245155@collabora.com Acked-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2024-12-23PCI: hookup irq_get_affinity callbackDaniel Wagner
struct bus_type has a new callback for retrieving the IRQ affinity for a device. Hook this callback up for PCI based devices. Acked-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: John Garry <john.g.garry@oracle.com> Signed-off-by: Daniel Wagner <wagi@kernel.org> Link: https://lore.kernel.org/r/20241202-refactor-blk-affinity-helpers-v6-2-27211e9c2cd5@kernel.org Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-12-21Merge tag 'pci-v6.13-fixes-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci Pull PCI fixes from Krzysztof Wilczyński: "Two small patches that are important for fixing boot time hang on Intel JHL7540 'Titan Ridge' platforms equipped with a Thunderbolt controller. The boot time issue manifests itself when a PCI Express bandwidth control is unnecessarily enabled on the Thunderbolt controller downstream ports, which only supports a link speed of 2.5 GT/s in accordance with USB4 v2 specification (p. 671, sec. 11.2.1, "PCIe Physical Layer Logical Sub-block"). As such, there is no need to enable bandwidth control on such downstream port links, which also works around the issue. Both patches were tested by the original reporter on the hardware on which the failure origin golly manifested itself. Both fixes were proven to resolve the reported boot hang issue, and both patches have been in linux-next this week with no reported problems" * tag 'pci-v6.13-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: PCI/bwctrl: Enable only if more than one speed is supported PCI: Honor Max Link Speed when determining supported speeds
2024-12-19PCI/bwctrl: Enable only if more than one speed is supportedLukas Wunner
If a PCIe port only supports a single speed, enabling bandwidth control is pointless: There's no need to monitor autonomous speed changes, nor can the speed be changed. Not enabling it saves a small amount of memory and compute resources, but also fixes a boot hang reported by Niklas: It occurs when enabling bandwidth control on Downstream Ports of Intel JHL7540 "Titan Ridge 2018" Thunderbolt controllers. The ports only support 2.5 GT/s in accordance with USB4 v2 sec 11.2.1, so the present commit works around the issue. PCIe r6.2 sec 8.2.1 prescribes that: "A device must support 2.5 GT/s and is not permitted to skip support for any data rates between 2.5 GT/s and the highest supported rate." Consequently, bandwidth control is currently only disabled if a port doesn't support higher speeds than 2.5 GT/s. However the Implementation Note in PCIe r6.2 sec 7.5.3.18 cautions: "It is strongly encouraged that software primarily utilize the Supported Link Speeds Vector instead of the Max Link Speed field, so that software can determine the exact set of supported speeds on current and future hardware. This can avoid software being confused if a future specification defines Links that do not require support for all slower speeds." In other words, future revisions of the PCIe Base Spec may allow gaps in the Supported Link Speeds Vector. To be future-proof, don't just check whether speeds above 2.5 GT/s are supported, but rather check whether *more than one* speed is supported. Fixes: 665745f27487 ("PCI/bwctrl: Re-add BW notification portdrv as PCIe BW controller") Closes: https://lore.kernel.org/r/db8e457fcd155436449b035e8791a8241b0df400.camel@kernel.org Link: https://lore.kernel.org/r/3564908a9c99fc0d2a292473af7a94ebfc8f5820.1734428762.git.lukas@wunner.de Reported-by: Niklas Schnelle <niks@kernel.org> Tested-by: Niklas Schnelle <niks@kernel.org> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Jonathan Cameron <Jonthan.Cameron@huawei.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-12-19PCI: Honor Max Link Speed when determining supported speedsLukas Wunner
The Supported Link Speeds Vector in the Link Capabilities 2 Register indicates the *supported* link speeds. The Max Link Speed field in the Link Capabilities Register indicates the *maximum* of those speeds. pcie_get_supported_speeds() neglects to honor the Max Link Speed field and will thus incorrectly deem higher speeds as supported. Fix it. One user-visible issue addressed here is an incorrect value in the sysfs attribute "max_link_speed". But the main motivation is a boot hang reported by Niklas: Intel JHL7540 "Titan Ridge 2018" Thunderbolt controllers supports 2.5-8 GT/s speeds, but indicate 2.5 GT/s as maximum. Ilpo recalls seeing this on more devices. It can be explained by the controller's Downstream Ports supporting 8 GT/s if an Endpoint is attached, but limiting to 2.5 GT/s if the port interfaces to a PCIe Adapter, in accordance with USB4 v2 sec 11.2.1: "This section defines the functionality of an Internal PCIe Port that interfaces to a PCIe Adapter. [...] The Logical sub-block shall update the PCIe configuration registers with the following characteristics: [...] Max Link Speed field in the Link Capabilities Register set to 0001b (data rate of 2.5 GT/s only). Note: These settings do not represent actual throughput. Throughput is implementation specific and based on the USB4 Fabric performance." The present commit is not sufficient on its own to fix Niklas' boot hang, but it is a prerequisite: A subsequent commit will fix the boot hang by enabling bandwidth control only if more than one speed is supported. The GENMASK() macro used herein specifies 0 as lowest bit, even though the Supported Link Speeds Vector ends at bit 1. This is done on purpose to avoid a GENMASK(0, 1) macro if Max Link Speed is zero. That macro would be invalid as the lowest bit is greater than the highest bit. Ilpo has witnessed a zero Max Link Speed on Root Complex Integrated Endpoints in particular, so it does occur in practice. (The Link Capabilities Register is optional on RCiEPs per PCIe r6.2 sec 7.5.3.) Fixes: d2bd39c0456b ("PCI: Store all PCIe Supported Link Speeds") Closes: https://lore.kernel.org/r/70829798889c6d779ca0f6cd3260a765780d1369.camel@kernel.org Link: https://lore.kernel.org/r/fe03941e3e1cc42fb9bf4395e302bff53ee2198b.1734428762.git.lukas@wunner.de Reported-by: Niklas Schnelle <niks@kernel.org> Tested-by: Niklas Schnelle <niks@kernel.org> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-12-18PCI: xilinx-cpm: Add support for Versal CPM5 Root Port Controller 1Thippeswamy Havalige
Add support for the Xilinx Versal CPM5 Root Port Controller 1. The key difference between Controller 0 and Controller 1 lies in the platform-specific error interrupt bits, which are located at different register offsets. To handle these differences, updated variant structure to hold the following platform-specific details: - Interrupt status register offset (ir_status) - Interrupt enable register offset (ir_enable) - Miscellaneous interrupt values (ir_misc_value) The driver differentiates between Controller 0 and Controller 1 using the compatible string in the device tree. This ensures that the appropriate register offsets are used for each controller, allowing for correct handling of platform-specific interrupts and initialization. Link: https://lore.kernel.org/r/20240922061318.2653503-3-thippesw@amd.com Signed-off-by: Thippeswamy Havalige <thippesw@amd.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
generated by cgit (git 2.34.1) at 2025-07-16 10:30:43 +0000