summaryrefslogtreecommitdiff
path: root/drivers/pci/controller/dwc/pcie-designware-ep.c
AgeCommit message (Collapse)Author
2025-06-04Merge branch 'pci/ptm-debugfs'Bjorn Helgaas
- Add debugfs support for exposing DWC device-specific PTM context (Manivannan Sadhasivam) * pci/ptm-debugfs: PCI: qcom-ep: Mask PTM_UPDATING interrupt PCI: dwc: Add debugfs support for PTM context PCI: dwc: Pass DWC PCIe mode to dwc_pcie_debugfs_init() PCI: Add debugfs support for exposing PTM context
2025-06-04Merge branch 'pci/controller/dwc-ep'Bjorn Helgaas
- Use FIELD_GET() to simplify extracting register values (Hans Zhang) * pci/controller/dwc-ep: PCI: dwc: ep: Fix errno typo PCI: dwc: ep: Use FIELD_GET() where applicable
2025-05-28PCI: endpoint: Align pci_epc_set_msix(), pci_epc_ops::set_msix() nr_irqs ↵Niklas Cassel
encoding The kdoc for pci_epc_set_msix() says: "Invoke to set the required number of MSI-X interrupts." The kdoc for the callback pci_epc_ops->set_msix() says: "ops to set the requested number of MSI-X interrupts in the MSI-X capability register" pci_epc_ops::set_msix() does however expect the parameter 'interrupts' to be in the encoding as defined by the Table Size field. Nowhere in the kdoc does it say that the number of interrupts should be in Table Size encoding. It is very confusing that the API pci_epc_set_msix() and the callback function pci_epc_ops::set_msix() both take a parameter named 'interrupts', but they expect completely different encodings. Clean up the API and the callback function to have the same semantics, i.e. the parameter represents the number of interrupts, regardless of the internal encoding of that value. Also rename the parameter 'interrupts' to 'nr_irqs', in both the wrapper function and the callback function, such that the name is unambiguous. [bhelgaas: more specific subject] Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable+noautosel@kernel.org # this is simply a cleanup Link: https://patch.msgid.link/20250514074313.283156-14-cassel@kernel.org
2025-05-28PCI: endpoint: Align pci_epc_set_msi(), pci_epc_ops::set_msi() nr_irqs encodingNiklas Cassel
The kdoc for pci_epc_set_msi() says: "Invoke to set the required number of MSI interrupts." The kdoc for the callback pci_epc_ops::set_msi() says: "ops to set the requested number of MSI interrupts in the MSI capability register" pci_epc_ops::set_msi() does however expect the parameter 'interrupts' to be in the encoding as defined by the Multiple Message Capable (MMC) field of the MSI capability structure. Nowhere in the kdoc does it say that the number of interrupts should be in MMC encoding. It is very confusing that the API pci_epc_set_msi() and the callback function pci_epc_ops::set_msi() both take a parameter named 'interrupts', but they expect completely different encodings. Clean up the API and the callback function to have the same semantics, i.e. the parameter represents the number of interrupts, regardless of the internal encoding of that value. Also rename the parameter 'interrupts' to 'nr_irqs', in both the wrapper function and the callback function, such that the name is unambiguous. [bhelgaas: more specific subject] Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable+noautosel@kernel.org # this is simply a cleanup Link: https://patch.msgid.link/20250514074313.283156-13-cassel@kernel.org
2025-05-28PCI: endpoint: Align pci_epc_get_msix(), pci_epc_ops::get_msix() return ↵Niklas Cassel
value encoding The kdoc for pci_epc_get_msix() says: "Invoke to get the number of MSI-X interrupts allocated by the RC" The kdoc for the callback pci_epc_ops->get_msix() says: "ops to get the number of MSI-X interrupts allocated by the RC from the MSI-X capability register" pci_epc_ops::get_msix() does however return the number of interrupts in the encoding as defined by the Table Size field. Nowhere in the kdoc does it say that the returned number of interrupts is in Table Size encoding. It is very confusing that the API pci_epc_get_msix() and the callback function pci_epc_ops::get_msix() don't return the same value. Clean up the API and the callback function to have the same semantics, i.e. return the number of interrupts, regardless of the internal encoding of that value. [bhelgaas: more specific subject] Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Cc: stable+noautosel@kernel.org # this is simply a cleanup Link: https://patch.msgid.link/20250514074313.283156-12-cassel@kernel.org
2025-05-28PCI: endpoint: Align pci_epc_get_msi(), pci_epc_ops::get_msi() return value ↵Niklas Cassel
encoding The kdoc for API pci_epc_get_msi() says: "Invoke to get the number of MSI interrupts allocated by the RC" The kdoc for the callback pci_epc_ops::get_msi() says: "ops to get the number of MSI interrupts allocated by the RC from the MSI capability register" pci_epc_ops::get_msi() does however return the number of interrupts in the encoding as defined by the Multiple Message Enable (MME) field of the MSI Capability structure. Nowhere in the kdoc does it say that the returned number of interrupts is in MME encoding. It is very confusing that the API pci_epc_get_msi() and the callback function pci_epc_ops::get_msi() don't return the same value. Clean up the API and the callback function to have the same semantics, i.e. return the number of interrupts, regardless of the internal encoding of that value. [bhelgaas: more specific subject] Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Cc: stable+noautosel@kernel.org # this is simply a cleanup Link: https://patch.msgid.link/20250514074313.283156-11-cassel@kernel.org
2025-05-28PCI: dwc: ep: Correct PBA offset in .set_msix() callbackNiklas Cassel
While dw_pcie_ep_set_msix() writes the Table Size field correctly (N-1), the calculation of the PBA offset is wrong because it calculates space for (N-1) entries instead of N. This results in the following QEMU error when using PCI passthrough on a device which relies on the PCI endpoint subsystem: failed to add PCI capability 0x11[0x50]@0xb0: table & pba overlap, or they don't fit in BARs, or don't align Fix the calculation of PBA offset in the MSI-X capability. [bhelgaas: more specific subject and commit log] Fixes: 83153d9f36e2 ("PCI: endpoint: Fix ->set_msix() to take BIR and offset as arguments") Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250514074313.283156-9-cassel@kernel.org
2025-05-20PCI: dwc: ep: Fix errno typoNiklas Cassel
Fix errno typo in kernel-doc comments. Fixes: 7cbebc86c72a ("PCI: dwc: ep: Add Kernel-doc comments for APIs") Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20250506095138.482485-2-cassel@kernel.org
2025-05-15PCI: dwc: Pass DWC PCIe mode to dwc_pcie_debugfs_init()Manivannan Sadhasivam
Upcoming PTM debugfs interface relies on the DWC PCIe mode to expose the relevant debugfs attributes to userspace. So pass the mode to dwc_pcie_debugfs_init() API from host and ep drivers and save it in 'struct dw_pcie::mode'. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Link: https://patch.msgid.link/20250505-pcie-ptm-v4-2-02d26d51400b@linaro.org
2025-05-10PCI: dwc: ep: Use FIELD_GET() where applicableHans Zhang
Use FIELD_GET() to simplify the code extracting the register values. No functional change intended. Signed-off-by: Hans Zhang <18255117159@163.com> [mani: commit message fixup] Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Niklas Cassel <cassel@kernel.org> Link: https://patch.msgid.link/20250428124230.112648-1-18255117159@163.com
2025-03-27Merge branch 'pci/controller/dwc-cpu-addr-fixup'Bjorn Helgaas
- Ioremap() msg_res region using res->start (the CPU address), not the ATU 'cpu_addr', which will be replaced with the ATU input address (which may not be the CPU address) (Frank Li) - Rename struct dw_pcie_ob_atu_cfg.cpu_addr to 'parent_bus_addr' (Frank Li) - Call devm_pci_alloc_host_bridge() early in dw_pcie_host_init() to keep devicetree-related code together (Frank Li) - Consolidate devicetree handling in dw_pcie_host_get_resources() (Bjorn Helgaas) - Add dw_pcie_parent_bus_offset() to look up the parent bus address of a specified 'reg' property and return the offset from the CPU physical address (Frank Li) - Add cross-checking with .cpu_addr_fixup() and debug logging to dw_pcie_parent_bus_offset() (Frank Li) - Use devicetree 'reg[config]' via dw_pcie_parent_bus_offset() to derive CPU -> ATU addr offset for host controller (Frank Li) - Call epc_create() early in dw_pcie_ep_init() to keep devicetree-related code together (Bjorn Helgaas) - Consolidate devicetree handling in dw_pcie_ep_get_resources() (Bjorn Helgaas) - Use devicetree 'reg[addr_space]' via dw_pcie_parent_bus_offset() to derive CPU -> ATU addr offset for endpoint controller (Frank Li) - Update dw_pcie_find_index() to remove assumption that ATU input address is non-zero (Frank Li) - Apply struct dw_pcie.parent_bus_offset in ATU users to remove use of .cpu_addr_fixup() when programming ATU (Frank Li) - Remove imx_pcie_cpu_addr_fixup() since dwc core can now derive the ATU input address (using parent_bus_offset) from devicetree (Frank Li) - Remove intel_pcie_cpu_addr() since dwc core can now derive the ATU input address (using parent_bus_offset) from devicetree (Frank Li) * pci/controller/dwc-cpu-addr-fixup: PCI: intel-gw: Remove intel_pcie_cpu_addr() PCI: imx6: Remove imx_pcie_cpu_addr_fixup() PCI: dwc: Use parent_bus_offset to remove need for .cpu_addr_fixup() PCI: dwc: ep: Ensure proper iteration over outbound map windows PCI: dwc: ep: Use devicetree 'reg[addr_space]' to derive CPU -> ATU addr offset PCI: dwc: ep: Consolidate devicetree handling in dw_pcie_ep_get_resources() PCI: dwc: ep: Call epc_create() early in dw_pcie_ep_init() PCI: dwc: Use devicetree 'reg[config]' to derive CPU -> ATU addr offset PCI: dwc: Add dw_pcie_parent_bus_offset() checking and debug PCI: dwc: Add dw_pcie_parent_bus_offset() PCI: dwc: Consolidate devicetree handling in dw_pcie_host_get_resources() PCI: dwc: Call devm_pci_alloc_host_bridge() early in dw_pcie_host_init() PCI: dwc: Rename cpu_addr to parent_bus_addr for ATU configuration PCI: dwc: Use resource start as ioremap() input in dw_pcie_pme_turn_off() # Conflicts: # drivers/pci/controller/dwc/pcie-designware.c # drivers/pci/controller/dwc/pcie-designware.h
2025-03-27Merge branch 'pci/controller/dwc'Bjorn Helgaas
- Move struct dwc_pcie_vsec_id to include/linux/pcie-dwc.h, where it can be shared by debugfs, perf, sysfs, etc (Manivannan Sadhasivam) - Add dw_pcie_find_vsec_capability() to locate Vendor Specific Extended Capabilities (Shradha Todi) - Add debugfs-based Silicon Debug, Error Injection, Statistical Counter support for DWC (Shradha Todi) - Add debugfs property to expose LTSSM status of DWC PCIe link (Hans Zhang) - Add Rockchip Vendor ID and Vendor Specific ID of RAS DES Capability so the DWC debugfs features work for Rockchip as well (Niklas Cassel) * pci/controller/dwc: PCI: dw-rockchip: Hide broken ATS capability for RK3588 running in EP mode PCI: dwc: ep: Add dw_pcie_ep_hide_ext_capability() PCI: dwc: ep: Return -ENOMEM for allocation failures PCI: dwc: Add Rockchip to the RAS DES allowed vendor list PCI: Add Rockchip Vendor ID PCI: dwc: Add debugfs property to provide LTSSM status of the PCIe link PCI: dwc: Add debugfs based Statistical Counter support for DWC PCI: dwc: Add debugfs based Error Injection support for DWC PCI: dwc: Add debugfs based Silicon Debug support for DWC PCI: dwc: Add helper to find the Vendor Specific Extended Capability (VSEC) perf/dwc_pcie: Move common DWC struct definitions to 'pcie-dwc.h'
2025-03-24PCI: dwc: Use parent_bus_offset to remove need for .cpu_addr_fixup()Frank Li
We know the parent_bus_offset, either computed from a DT reg property (the offset is the CPU physical addr - the 'config'/'addr_space' address on the parent bus) or from a .cpu_addr_fixup() (which may have used a host bridge window offset). Apply that parent_bus_offset instead of calling .cpu_addr_fixup() when programming the ATU. This assumes all intermediate addresses are at the same offset from the CPU physical addresses. [bhelgaas: commit log] Link: https://lore.kernel.org/r/20250315201548.858189-13-helgaas@kernel.org Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2025-03-24PCI: dwc: ep: Ensure proper iteration over outbound map windowsFrank Li
Most systems' PCIe outbound map windows have non-zero physical addresses, but the possibility of encountering zero increased after following commit ("PCI: dwc: Use parent_bus_offset"). 'ep->outbound_addr[n]', representing 'parent_bus_address', might be 0 on some hardware, which trims high address bits through bus fabric before sending to the PCIe controller. Replace the iteration logic with 'for_each_set_bit()' to ensure only allocated map windows are iterated when determining the ATU index from a given address. Link: https://lore.kernel.org/r/20250315201548.858189-12-helgaas@kernel.org Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2025-03-24PCI: dwc: ep: Use devicetree 'reg[addr_space]' to derive CPU -> ATU addr offsetFrank Li
Endpoint ┌───────────────────────────────────────────────┐ │ pcie-ep@5f010000 │ │ ┌────────────────┐│ │ │ Endpoint ││ │ │ PCIe ││ │ │ Controller ││ │ bus@5f000000 │ ┌────────► │ ┌──────────┐ │ │ ││dynamically │ │ │ Outbound Transfer │ ││allocated │┌─────┐ │ Bus ┼─────►│ ATU ───────┘ ││PCI Addr ││ │ │ Fabric │Bus │ ││ ││ CPU ├───►│ │Addr │ ││ ││ │CPU │ │0x8000_0000 ││ │└─────┘Addr└──────────┘ │ ││ │ 0x7000_0000 └────────────────┘│ └───────────────────────────────────────────────┘ bus@5f000000 { compatible = "simple-bus"; ranges = <0x80000000 0x0 0x70000000 0x10000000>; pcie-ep@5f010000 { reg = <0x80000000 0x10000000>; reg-names ="addr_space"; ... }; ... }; In the diagram above, CPU writes data to outbound window address 0x7000_0000, and the bus fabric maps it to 0x8000_0000. The ATU uses bus address 0x8000_0000 as input address and maps to some PCI address dynamically allocated by a PCI device driver on the host side. The pcie-ep@5f010000 'reg[addr_space]' is the parent bus address, which is the input of PCIe controller, including the ATU. Set parent_bus_offset, the offset from the CPU address to the PCIe controller input address using dw_pcie_init_parent_bus_offset(). The parent_bus_offset is not used yet, so no functional change intended. [bhelgaas: commit log] Link: https://lore.kernel.org/r/20250315201548.858189-11-helgaas@kernel.org Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2025-03-24PCI: dwc: ep: Consolidate devicetree handling in dw_pcie_ep_get_resources()Bjorn Helgaas
Consolidate devicetree resource handling in dw_pcie_ep_get_resources(). No functional change intended. Link: https://lore.kernel.org/r/20250315201548.858189-10-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Frank Li <Frank.Li@nxp.com>
2025-03-24PCI: dwc: ep: Call epc_create() early in dw_pcie_ep_init()Bjorn Helgaas
Move devm_pci_epc_create() to the beginning of dw_pcie_ep_init(). devm_pci_epc_create() is generic code that doesn't depend on any DWC resource, so moving it earlier keeps all the subsequent devicetree-related code together. Link: https://lore.kernel.org/r/20250315201548.858189-9-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Frank Li <Frank.Li@nxp.com>
2025-03-17PCI: dwc: Rename cpu_addr to parent_bus_addr for ATU configurationFrank Li
Rename 'cpu_addr' to 'parent_bus_addr' in the DesignWare ATU configuration. The ATU translates parent bus addresses to PCI addresses, which are often the same as CPU addresses but can differ in systems where the bus fabric translates addresses before passing them to the PCIe controller. This renaming clarifies the purpose and avoids confusion. Link: https://lore.kernel.org/r/20250315201548.858189-3-helgaas@kernel.org Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2025-03-14PCI: dwc: ep: Add dw_pcie_ep_hide_ext_capability()Niklas Cassel
Add dw_pcie_ep_hide_ext_capability() which can be used by an endpoint controller driver to hide a capability. This can be useful to hide a capability that is buggy, such that the host side does not try to enable the buggy capability. Suggested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Link: https://lore.kernel.org/r/20250310094826.842681-5-cassel@kernel.org
2025-03-14PCI: dwc: ep: Return -ENOMEM for allocation failuresDan Carpenter
If the bitmap or memory allocations fail, then dw_pcie_ep_init_registers() will incorrectly return a success. Return -ENOMEM instead. Fixes: 869bc5253406 ("PCI: dwc: ep: Fix DBI access failure for drivers requiring refclk from host") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Krzysztof Wilczyński <kw@linux.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/36dcb6fc-f292-4dd5-bd45-a8c6f9dc3df7@stanley.mountain
2025-03-08PCI: dwc: ep: Remove superfluous function dw_pcie_ep_find_ext_capability()Niklas Cassel
Remove the superfluous function dw_pcie_ep_find_ext_capability(), as it is virtually identical to dw_pcie_find_ext_capability(). Signed-off-by: Niklas Cassel <cassel@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20250221202646.395252-3-cassel@kernel.org Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
2025-03-08PCI: dwc: ep: Allow EPF drivers to configure the size of Resizable BARsNiklas Cassel
The DWC databook specifies three different BARn_SIZING_SCHEME_N as: - Fixed Mask (0) - Programmable Mask (1) - Resizable BAR (2) Each of these sizing schemes have different instructions for how to initialize the BAR. The DWC driver currently does not support resizable BARs. Instead, in order to somewhat support resizable BARs, the DWC EP driver currently has an ugly hack that force sets a resizable BAR to 1 MB, if such a BAR is detected. Additionally, this hack only works if the DWC glue driver also has lied in their EPC features, and claimed that the resizable BAR is a 1 MB fixed size BAR. This is unintuitive (as you somehow need to know that you need to lie in your EPC features), but other than that it is overly restrictive, since a resizable BAR is capable of supporting sizes different than 1 MB. Add proper support for resizable BARs in the DWC EP driver. Note that the pci_epc_set_bar() API takes a struct pci_epf_bar which tells the EPC driver how it wants to configure the BAR. struct pci_epf_bar only has a single size struct member. This means that an EPC driver will only be able to set a single supported size. This is perfectly fine, as we do not need the complexity of allowing a host to change the size of the BAR. If someone ever wants to support resizing a resizable BAR, the pci_epc_set_bar() API can be extended in the future. With these changes, we allow an EPF driver to configure the size of Resizable BARs, rather than forcing them to a 1 MB size. This means that an EPC driver does not need to lie in EPC features, and an EPF driver will be able to set an arbitrary size (not be forced to a 1 MB size), just like BAR_PROGRAMMABLE. Signed-off-by: Niklas Cassel <cassel@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20250131182949.465530-13-cassel@kernel.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
2025-03-08PCI: dwc: ep: Move dw_pcie_ep_find_ext_capability()Niklas Cassel
Move dw_pcie_ep_find_ext_capability() so that it is located next to dw_pcie_ep_find_capability(). Additionally, a follow-up commit requires this to be defined earlier in order to avoid a forward declaration. Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Niklas Cassel <cassel@kernel.org> Link: https://lore.kernel.org/r/20250131182949.465530-12-cassel@kernel.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
2025-03-06PCI: dwc: Add debugfs based Silicon Debug support for DWCShradha Todi
Add support to provide Silicon Debug interface to userspace. This set of debug registers are part of the RAS DES feature present in DesignWare PCIe controllers. Co-developed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Shradha Todi <shradha.t@samsung.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Fan Ni <fan.ni@samsung.com> Tested-by: Hrishikesh Deleep <hrishikesh.d@samsung.com> Link: https://lore.kernel.org/r/20250221131548.59616-4-shradha.t@samsung.com [kwilczynski: commit log, tidy up Kconfig and drop "default y", tidy up code comments, squashed patch that fixes a NULL pointer dereference when debugfs is already unavailable during clean-up from https://lore.kernel.org/linux-pci/20250225171239.19574-2-manivannan.sadhasivam@linaro.org, refactor dwc_pcie_debugfs_init() to not return errors, squashed patch that changes how lack of the RAS DES capability is handled from https://lore.kernel.org/linux-pci/20250304151814.6xu7cbpwpqrvcad5@thinkpad] Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
2024-12-18PCI: dwc: ep: Add 'address' alignment to 'size' check in ↵Niklas Cassel
dw_pcie_prog_ep_inbound_atu() dw_pcie_prog_ep_inbound_atu() is used to program an inbound iATU in "BAR Match Mode". A memory address returned by e.g. kmalloc() is guaranteed to have natural alignment (aligned to the size of the allocation). It is however not guaranteed that pci_epc_set_bar() (and thus dw_pcie_prog_ep_inbound_atu()) is supplied an address that has natural alignment. (An EPF driver can send in an arbitrary physical address to pci_epc_set_bar().) The DWC Databook description for the LWR_TARGET_RW and LWR_TARGET_HW fields in the IATU_LWR_TARGET_ADDR_OFF_INBOUND_i registers state that: "Field size depends on log2(BAR_MASK+1) in BAR match mode." I.e. only the upper bits are writable, and the number of writable bits is dependent on the configured BAR_MASK. Add a check to ensure that the physical address programmed in the iATU is aligned to the size of the BAR (BAR_MASK+1), as without this, we can get hard to debug errors, as we could write to bits that are read-only (without getting a write error), which could cause the iATU to end up redirecting to a physical address that is different from the address that we intended. Link: https://lore.kernel.org/r/20241213143301.4158431-11-cassel@kernel.org Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-12-18PCI: dwc: ep: Prevent changing BAR size/flags in pci_epc_set_bar()Niklas Cassel
In commit 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update inbound map address") set_bar() was modified to support dynamically changing the backing physical address of a BAR that was already configured. This means that set_bar() can be called twice, without ever calling clear_bar() (as calling clear_bar() would clear the BAR's PCI address assigned by the host). This can only be done if the new BAR size/flags does not differ from the existing BAR configuration. Add these missing checks. If we allow set_bar() to set e.g. a new BAR size that differs from the existing BAR size, the new address translation range will be smaller than the BAR size already determined by the host, which would mean that a read past the new BAR size would pass the iATU untranslated, which could allow the host to read memory not belonging to the new struct pci_epf_bar. While at it, add comments which clarifies the support for dynamically changing the physical address of a BAR. (Which was also missing.) Fixes: 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update inbound map address") Link: https://lore.kernel.org/r/20241213143301.4158431-10-cassel@kernel.org Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Cc: stable@vger.kernel.org
2024-12-18PCI: dwc: ep: Write BAR_MASK before iATU registers in pci_epc_set_bar()Niklas Cassel
The "DesignWare Cores PCI Express Controller Register Descriptions, Version 4.60a", section "1.21.70 IATU_LWR_TARGET_ADDR_OFF_INBOUND_i", fields LWR_TARGET_RW and LWR_TARGET_HW both state that: "Field size depends on log2(BAR_MASK+1) in BAR match mode." I.e. only the upper bits are writable, and the number of writable bits is dependent on the configured BAR_MASK. If we do not write the BAR_MASK before writing the iATU registers, we are relying the reset value of the BAR_MASK being larger than the requested BAR size (which is supplied in the struct pci_epf_bar which is passed to pci_epc_set_bar()). The reset value of the BAR_MASK is SoC dependent. Thus, if the struct pci_epf_bar requests a BAR size that is larger than the reset value of the BAR_MASK, the iATU will try to write to read-only bits, which will cause the iATU to end up redirecting to a physical address that is different from the address that was intended. Thus, we should always write the iATU registers after writing the BAR_MASK. Fixes: f8aed6ec624f ("PCI: dwc: designware: Add EP mode support") Link: https://lore.kernel.org/r/20241213143301.4158431-9-cassel@kernel.org Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Cc: stable@vger.kernel.org
2024-11-25Merge branch 'pci/controller/dwc'Bjorn Helgaas
- Clear outbound address on unmap so dw_pcie_find_index() won't match an ATU index that was already unmapped (Damien Le Moal) - Use of_property_present() instead of of_property_read_bool() when testing for presence of non-boolean DT properties (Rob Herring) - Advertise 1MB size if endpoint supports Resizable BARs, which was inadvertently lost in v6.11 (Niklas Cassel) * pci/controller/dwc: PCI: dwc: ep: Fix advertised resizable BAR size regression PCI: dwc: Use of_property_present() for non-boolean properties PCI: dwc: endpoint: Clear outbound address on unmap
2024-11-16PCI: dwc: ep: Fix advertised resizable BAR size regressionNiklas Cassel
The advertised resizable BAR size was fixed in commit 72e34b8593e0 ("PCI: dwc: endpoint: Fix advertised resizable BAR size"). Commit 867ab111b242 ("PCI: dwc: ep: Add a generic dw_pcie_ep_linkdown() API to handle Link Down event") was included shortly after this, and moved the code to another function. When the code was moved, this fix was mistakenly lost. According to the spec, it is illegal to not have a bit set in PCI_REBAR_CAP, and 1 MB is the smallest size allowed. So, set bit 4 in PCI_REBAR_CAP, so that we actually advertise support for a 1 MB BAR size. Fixes: 867ab111b242 ("PCI: dwc: ep: Add a generic dw_pcie_ep_linkdown() API to handle Link Down event") Link: https://lore.kernel.org/r/20241116005950.2480427-2-cassel@kernel.org Link: https://lore.kernel.org/r/20240606-pci-deinit-v1-3-4395534520dc@linaro.org Link: https://lore.kernel.org/r/20240307111520.3303774-1-cassel@kernel.org Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Cc: stable@vger.kernel.org
2024-11-16PCI: dwc: ep: Use align addr function for dw_pcie_ep_raise_{msi,msix}_irq()Niklas Cassel
Use the dw_pcie_ep_align_addr() function to calculate the alignment in dw_pcie_ep_raise_{msi,msix}_irq() instead of open coding the same. Link: https://lore.kernel.org/r/20241017132052.4014605-6-cassel@kernel.org Link: https://lore.kernel.org/r/20241104205144.409236-2-cassel@kernel.org Tested-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Niklas Cassel <cassel@kernel.org> [kwilczynski: squashed patch that fixes memory map sizes] Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-11-04PCI: dwc: endpoint: Implement the pci_epc_ops::align_addr() operationDamien Le Moal
The function dw_pcie_prog_outbound_atu() used to program outbound ATU entries for mapping RC PCI addresses to local CPU addresses does not allow PCI addresses that are not aligned to the value of region_align of struct dw_pcie. This value is determined from the iATU hardware registers during probing of the iATU (done by dw_pcie_iatu_detect()). This value is thus valid for all DWC PCIe controllers, and valid regardless of the hardware configuration used when synthesizing the DWC PCIe controller. Implement the ->align_addr() endpoint controller operation to allow this mapping alignment to be transparently handled by endpoint function drivers through the function pci_epc_mem_map(). Link: https://lore.kernel.org/linux-pci/20241012113246.95634-7-dlemoal@kernel.org Link: https://lore.kernel.org/linux-pci/20241015090712.112674-1-dlemoal@kernel.org Link: https://lore.kernel.org/linux-pci/20241017132052.4014605-5-cassel@kernel.org Co-developed-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Damien Le Moal <dlemoal@kernel.org> [mani: squashed the patch that changed phy_addr_t to u64] Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> [kwilczynski: squashed patch that updated the pci_size variable] Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-10-27PCI: dwc: endpoint: Clear outbound address on unmapDamien Le Moal
Clear the address mapped (outbound_addr array) in dw_pcie_ep_unmap_addr(), to ensure that dw_pcie_find_index() does not match an ATU index that was already unmapped. This is in addition to clearing the ATU index bit in ob_window_map. Link: https://lore.kernel.org/linux-pci/20241004141000.5080-1-dlemoal@kernel.org Signed-off-by: Damien Le Moal <dlemoal@kernel.org> [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-07-09PCI: dwc: ep: Enforce DWC specific 64-bit BAR limitationNiklas Cassel
From the DWC EP databook 5.96a, section "3.5.7.1.4 General Rules for BAR Setup (Fixed Mask or Programmable Mask Schemes Only)": "Any pair (for example BARs 0 and 1) can be configured as one 64-bit BAR, two 32-bit BARs, or one 32-bit BAR." "BAR pairs cannot overlap to form a 64-bit BAR. For example, you cannot combine BARs 1 and 2 to form a 64-bit BAR." While this limitation does exist in some other PCI endpoint controllers, e.g. cdns_pcie_ep_set_bar(), the limitation does not appear to be defined in the PCIe specification itself, thus add an explicit check for this in dw_pcie_ep_set_bar() (rather than pci_epc_set_bar()). Link: https://lore.kernel.org/linux-pci/20240528134839.8817-2-cassel@kernel.org Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-07-09PCI: dwc: ep: Remove dw_pcie_ep_init_notify() wrapperManivannan Sadhasivam
Currently dw_pcie_ep_init_notify() wrapper just calls pci_epc_init_notify() directly, so this wrapper provides no benefit to the glue drivers. Remove it and call pci_epc_init_notify() directly from glue drivers. Suggested-by: Bjorn Helgaas <helgaas@kernel.org> Link: https://lore.kernel.org/linux-pci/20240606-pci-deinit-v1-1-4395534520dc@linaro.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Niklas Cassel <cassel@kernel.org>
2024-07-09PCI: dwc: ep: Add a generic dw_pcie_ep_linkdown() API to handle Link Down eventManivannan Sadhasivam
Per PCIe r6.0, sec 5.2, a Link Down event can happen under any of the following circumstances: 1. Fundamental/Hot reset 2. Link disable transmission by upstream component 3. Moving from L2/L3 to L0 In those cases, Link Down causes some non-sticky DWC registers to lose the state (like REBAR, etc.), so drivers need to reinitialize them to function properly once the link comes back again. This is not a problem for drivers supporting PERST# IRQ, since they can reinitialize the registers in the PERST# IRQ callback. But for the drivers not supporting PERST#, there is no way they can reinitialize the registers other than relying on Link Down IRQ received when the link goes down. So add a DWC generic API dw_pcie_ep_linkdown() that reinitializes the non-sticky registers and also notifies the EPF drivers about link going down. This API can also be used by the drivers supporting PERST# to handle the scenario (2) mentioned above. NOTE: For the sake of code organization, move the dw_pcie_ep_linkup() definition just above dw_pcie_ep_linkdown(). Link: https://lore.kernel.org/linux-pci/20240430-pci-epf-rework-v4-8-22832d0d456f@linaro.org Tested-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> [bhelgaas: update spec citation] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Niklas Cassel <cassel@kernel.org>
2024-07-09PCI: dwc: Consolidate args of dw_pcie_prog_outbound_atu() into a structureYoshihiro Shimoda
This is a preparation before adding the Msg-type outbound iATU mapping. The respective update will require two more arguments added to __dw_pcie_prog_outbound_atu(). That will make the already complicated function prototype even more hard to comprehend accepting _eight_ arguments. To prevent that and keep the code more-or-less readable, move all the outbound iATU-related arguments to a new config structure: struct dw_pcie_ob_atu_cfg, and pass a pointer to dw_pcie_prog_outbound_atu(). The structure should be locally defined and populated with the outbound iATU settings implied by the caller context. As a result of this change there is no longer need in having the two distinctive methods for the Host and Endpoint outbound iATU setups since the code can directly call the dw_pcie_prog_outbound_atu() method with the config structure populated, so drop dw_pcie_prog_ep_outbound_atu(). [kwilczynski: commit log] Link: https://lore.kernel.org/linux-pci/20240418-pme_msg-v8-2-a54265c39742@nxp.com Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
2024-07-09PCI: dwc: Fix index 0 incorrectly being interpreted as a free ATU slotFrank Li
When PERST# assert and deassert happens on the PERST# supported platforms, both iATU0 and iATU6 will map inbound window to BAR0. DMA will access the area that was previously allocated (iATU0) for BAR0, instead of the new area (iATU6) for BAR0. Right now, this isn't an issue because both iATU0 and iATU6 should translate inbound accesses to BAR0 to the same allocated memory area. However, having two separate inbound mappings for the same BAR is a disaster waiting to happen. The mappings between PCI BAR and iATU inbound window are maintained in the dw_pcie_ep::bar_to_atu[] array. While allocating a new inbound iATU map for a BAR, dw_pcie_ep_inbound_atu() API checks for the availability of the existing mapping in the array and if it is not found (i.e., value in the array indexed by the BAR is found to be 0), it allocates a new map value using find_first_zero_bit(). The issue is the existing logic failed to consider the fact that the map value '0' is a valid value for BAR0, so find_first_zero_bit() will return '0' as the map value for BAR0 (note that it returns the first zero bit position). Due to this, when PERST# assert + deassert happens on the PERST# supported platforms, the inbound window allocation restarts from BAR0 and the existing logic to find the BAR mapping will return '6' for BAR0 instead of '0' due to the fact that it considers '0' as an invalid map value. Fix this issue by always incrementing the map value before assigning to bar_to_atu[] array and then decrementing it while fetching. This will make sure that the map value '0' always represents the invalid mapping." Fixes: 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update inbound map address") Closes: https://lore.kernel.org/linux-pci/ZXsRp+Lzg3x%2Fnhk3@x1-carbon/ Link: https://lore.kernel.org/linux-pci/20240412160841.925927-1-Frank.Li@nxp.com Reported-by: Niklas Cassel <Niklas.Cassel@wdc.com> Tested-by: Niklas Cassel <niklas.cassel@wdc.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Niklas Cassel <niklas.cassel@wdc.com>
2024-07-04PCI: endpoint: Introduce 'epc_deinit' event and notify the EPF driversManivannan Sadhasivam
As like the 'epc_init' event, that is used to signal the EPF drivers about the EPC initialization, let's introduce 'epc_deinit' event that is used to signal EPC deinitialization. The EPC deinitialization applies only when any sort of fundamental reset is supported by the endpoint controller as per the PCIe spec. Reference: PCIe r6.0, sec 4.2.5.9.1 and 6.6.1. Currently, some EPC drivers like pcie-qcom-ep and pcie-tegra194 support PERST# as the fundamental reset. So the 'deinit' event will be notified to the EPF drivers when PERST# assert happens in the above mentioned EPC drivers. The EPF drivers, on receiving the event through the epc_deinit() callback should reset the EPF state machine and also cleanup any configuration that got affected by the fundamental reset like BAR, DMA etc... This change also warrants skipping the cleanups in unbind() if already done in epc_deinit(). Link: https://lore.kernel.org/r/20240606-pci-deinit-v1-2-4395534520dc@linaro.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Niklas Cassel <cassel@kernel.org> Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com> Reviewed-by: Frank Li <Frank.Li@nxp.com>
2024-04-10PCI: endpoint: Remove "core_init_notifier" flagManivannan Sadhasivam
"core_init_notifier" flag is set by the glue drivers requiring refclk from the host to complete the DWC core initialization. Also, those drivers will send a notification to the EPF drivers once the initialization is fully completed using the pci_epc_init_notify() API. Only then, the EPF drivers will start functioning. For the rest of the drivers generating refclk locally, EPF drivers will start functioning post binding with them. EPF drivers rely on the 'core_init_notifier' flag to differentiate between the drivers. Unfortunately, this creates two different flows for the EPF drivers. So to avoid that, let's get rid of the "core_init_notifier" flag and follow a single initialization flow for the EPF drivers. This is done by calling the dw_pcie_ep_init_notify() from all glue drivers after the completion of dw_pcie_ep_init_registers() API. This will allow all the glue drivers to send the notification to the EPF drivers once the initialization is fully completed. Only difference here is that, the drivers requiring refclk from host will send the notification once refclk is received, while others will send it during probe time itself. But this also requires the EPC core driver to deliver the notification after EPF driver bind. Because, the glue driver can send the notification before the EPF drivers bind() and in those cases the EPF drivers will miss the event. To accommodate this, EPC core is now caching the state of the EPC initialization in 'init_complete' flag and pci-ep-cfs driver sends the notification to EPF drivers based on that after each EPF driver bind. Link: https://lore.kernel.org/linux-pci/20240327-pci-dbi-rework-v12-8-082625472414@linaro.org Tested-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Niklas Cassel <cassel@kernel.org>
2024-04-10PCI: dwc: ep: Call dw_pcie_ep_init_registers() API directly from all glue ↵Manivannan Sadhasivam
drivers Currently, dw_pcie_ep_init_registers() API is directly called by the glue drivers requiring active refclk from host. But for the other drivers, it is getting called implicitly by dw_pcie_ep_init(). This is due to the fact that this API initializes DWC EP specific registers and that requires an active refclk (either from host or generated locally by endpoint itsef). But, this causes a discrepancy among the glue drivers. So to avoid this confusion, let's call this API directly from all glue drivers irrespective of refclk dependency. Only difference here is that the drivers requiring refclk from host will call this API only after the refclk is received and other drivers without refclk dependency will call this API right after dw_pcie_ep_init(). With this change, the check for 'core_init_notifier' flag can now be dropped from dw_pcie_ep_init() API. This will also allow us to remove the 'core_init_notifier' flag completely in the later commits. Link: https://lore.kernel.org/linux-pci/20240327-pci-dbi-rework-v12-7-082625472414@linaro.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Niklas Cassel <cassel@kernel.org> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
2024-04-10PCI: dwc: ep: Rename dw_pcie_ep_init_complete() to dw_pcie_ep_init_registers()Manivannan Sadhasivam
The goal of the dw_pcie_ep_init_complete() API is to initialize the DWC specific registers post registering the controller with the EP framework. But the naming doesn't reflect its functionality and causes confusion. So, let's rename it to dw_pcie_ep_init_registers() to make it clear that it initializes the DWC specific registers. Link: https://lore.kernel.org/linux-pci/20240327-pci-dbi-rework-v12-6-082625472414@linaro.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Niklas Cassel <cassel@kernel.org>
2024-04-10PCI: dwc: ep: Introduce dw_pcie_ep_cleanup() API for drivers supporting PERST#Manivannan Sadhasivam
For DWC glue drivers supporting PERST# (currently Qcom and Tegra194), some of the DWC resources like eDMA should be cleaned up during the PERST# assert time. So let's introduce a dw_pcie_ep_cleanup() API that could be called by these drivers to cleanup the DWC specific resources. Currently, it just removes eDMA. Closes: https://lore.kernel.org/linux-pci/ZWYmX8Y%2F7Q9WMxES@x1-carbon Link: https://lore.kernel.org/linux-pci/20240327-pci-dbi-rework-v12-5-082625472414@linaro.org Reported-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Niklas Cassel <cassel@kernel.org>
2024-04-10PCI: dwc: ep: Rename dw_pcie_ep_exit() to dw_pcie_ep_deinit()Manivannan Sadhasivam
dw_pcie_ep_exit() API is undoing what the dw_pcie_ep_init() API has done already (at least partly). But the API name dw_pcie_ep_exit() is not quite reflecting that. So let's rename it to dw_pcie_ep_deinit() to make the purpose of this API clear. This also aligns with the DWC host driver. Link: https://patchwork.kernel.org/project/linux-pci/patch/20240327-pci-dbi-rework-v12-4-082625472414@linaro.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Niklas Cassel <cassel@kernel.org> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
2024-04-10PCI: dwc: ep: Remove deinit() callback from struct dw_pcie_ep_opsManivannan Sadhasivam
deinit() callback was solely introduced for the pcie-rcar-gen4 driver where it is used to do platform specific resource deallocation. And this callback is called right at the end of the dw_pcie_ep_exit() API. So it doesn't matter whether it is called within or outside of dw_pcie_ep_exit() API. So let's remove this callback and directly call rcar_gen4_pcie_ep_deinit() in pcie-rcar-gen4 driver to do resource deallocation after the completion of dw_pcie_ep_exit() API in rcar_gen4_remove_dw_pcie_ep(). This simplifies the DWC layer. Link: https://lore.kernel.org/linux-pci/20240327-pci-dbi-rework-v12-3-082625472414@linaro.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Niklas Cassel <cassel@kernel.org> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
2024-04-10PCI: dwc: ep: Add Kernel-doc comments for APIsManivannan Sadhasivam
All of the APIs are missing the Kernel-doc comments. Hence, add them. Link: https://lore.kernel.org/linux-pci/20240327-pci-dbi-rework-v12-2-082625472414@linaro.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Niklas Cassel <cassel@kernel.org>
2024-04-10PCI: dwc: ep: Fix DBI access failure for drivers requiring refclk from hostManivannan Sadhasivam
The DWC glue drivers requiring an active reference clock from the PCIe host for initializing their PCIe EP core, set a flag called 'core_init_notifier' to let DWC driver know that these drivers need a special attention during initialization. In these drivers, access to the hw registers (like DBI) before receiving the active refclk from host will result in access failure and also could cause a whole system hang. But the current DWC EP driver doesn't honor the requirements of the drivers setting 'core_init_notifier' flag and tries to access the DBI registers during dw_pcie_ep_init(). This causes the system hang for glue drivers such as Tegra194 and Qcom EP as they depend on refclk from host and have set the above mentioned flag. To workaround this issue, users of the affected platforms have to maintain the dependency with the PCIe host by booting the PCIe EP after host boot. But this won't provide a good user experience, since PCIe EP is _one_ of the features of those platforms and it doesn't make sense to delay the whole platform booting due to PCIe requiring active refclk. So to fix this issue, let's move all the DBI access from dw_pcie_ep_init() in the DWC EP driver to the dw_pcie_ep_init_complete() API. This API will only be called by the drivers setting 'core_init_notifier' flag once refclk is received from host. For the rest of the drivers that gets the refclk locally, this API will be called within dw_pcie_ep_init(). Link: https://lore.kernel.org/linux-pci/20240327-pci-dbi-rework-v12-1-082625472414@linaro.org Fixes: e966f7390da9 ("PCI: dwc: Refactor core initialization code for EP mode") Co-developed-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Niklas Cassel <cassel@kernel.org>
2024-03-14Merge tag 'pci-v6.9-changes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci Pull PCI updates from Bjorn Helgaas: "Enumeration: - Consolidate interrupt related code in irq.c (Ilpo Järvinen) - Reduce kernel size by replacing sysfs resource macros with functions (Ilpo Järvinen) - Reduce kernel size by compiling sysfs support only when CONFIG_SYSFS=y (Lukas Wunner) - Avoid using Extended Tags on 3ware-9650SE Root Port to work around an apparent hardware defect (Jörg Wedekind) Resource management: - Fix an MMIO mapping leak in pci_iounmap() (Philipp Stanner) - Move pci_iomap.c and other PCI-specific devres code to drivers/pci (Philipp Stanner) - Consolidate PCI devres code in devres.c (Philipp Stanner) Power management: - Avoid D3cold on Asus B1400 PCI-NVMe bridge, where firmware doesn't know how to return correctly to D0, and remove previous quirk that wasn't as specific (Daniel Drake) - Allow runtime PM when the driver enables it but doesn't need any runtime PM callbacks (Raag Jadav) - Drain runtime-idle callbacks before driver removal to avoid races between .remove() and .runtime_idle(), which caused intermittent page faults when the rtsx .runtime_idle() accessed registers that its .remove() had already unmapped (Rafael J. Wysocki) Virtualization: - Avoid Secondary Bus Reset on LSI FW643 so it can be assigned to VMs with VFIO, e.g., for professional audio software on many Apple machines, at the cost of leaking state between VMs (Edmund Raile) Error handling: - Print all logged TLP Prefixes, not just the first, after AER or DPC errors (Ilpo Järvinen) - Quirk the DPC PIO log size for Intel Raptor Lake Root Ports, which still don't advertise a legal size (Paul Menzel) - Ignore expected DPC Surprise Down errors on hot removal (Smita Koralahalli) - Block runtime suspend while handling AER errors to avoid races that prevent the device form being resumed from D3hot (Stanislaw Gruszka) Peer-to-peer DMA: - Use atomic XA allocation in RCU read section (Christophe JAILLET) ASPM: - Collect bits of ASPM-related code that we need even without CONFIG_PCIEASPM into aspm.c (David E. Box) - Save/restore L1 PM Substates config for suspend/resume (David E. Box) - Update save_save when ASPM config is changed, so a .slot_reset() during error recovery restores the changed config, not the .probe()-time config (Vidya Sagar) Endpoint framework: - Refactor and improve pci_epf_alloc_space() API (Niklas Cassel) - Clean up endpoint BAR descriptions (Niklas Cassel) - Fix ntb_register_device() name leak in error path (Yang Yingliang) - Return actual error code for pci_vntb_probe() failure (Yang Yingliang) Broadcom STB PCIe controller driver: - Fix MDIO write polling, which previously never waited for completion (Jonathan Bell) Cadence PCIe endpoint driver: - Clear the ARI "Next Function Number" of last function (Jasko-EXT Wojciech) Freescale i.MX6 PCIe controller driver: - Simplify by replacing switch statements with function pointers for different hardware variants (Frank Li) - Simplify by using clk_bulk*() API (Frank Li) - Remove redundant DT clock and reg/reg-name details (Frank Li) - Add i.MX95 DT and driver support for both Root Complex and Endpoint mode (Frank Li) Microsoft Hyper-V host bridge driver: - Reduce memory usage by limiting ring buffer size to 16KB instead of 4 pages (Michael Kelley) Qualcomm PCIe controller driver: - Add X1E80100 DT and driver support (Abel Vesa) - Add DT 'required-opps' for SoCs that require a minimum performance level (Johan Hovold) - Make DT 'msi-map-mask' optional, depending on how MSI interrupts are mapped (Johan Hovold) - Disable ASPM L0s for sc8280xp, sa8540p and sa8295p because the PHY configuration isn't tuned correctly for L0s (Johan Hovold) - Split dt-binding qcom,pcie.yaml into qcom,pcie-common.yaml and separate files for SA8775p, SC7280, SC8180X, SC8280XP, SM8150, SM8250, SM8350, SM8450, SM8550 for easier reviewing (Krzysztof Kozlowski) - Enable BDF to SID translation by disabling bypass mode (Manivannan Sadhasivam) - Add endpoint MHI support for Snapdragon SA8775P SoC (Mrinmay Sarkar) Synopsys DesignWare PCIe controller driver: - Allocate 64-bit MSI address if no 32-bit address is available (Ajay Agarwal) - Fix endpoint Resizable BAR to actually advertise the required 1MB size (Niklas Cassel) MicroSemi Switchtec management driver: - Release resources if the .probe() fails (Christophe JAILLET) Miscellaneous: - Make pcie_port_bus_type const (Ricardo B. Marliere)" * tag 'pci-v6.9-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: (77 commits) PCI/ASPM: Update save_state when configuration changes PCI/ASPM: Disable L1 before configuring L1 Substates PCI/ASPM: Call pci_save_ltr_state() from pci_save_pcie_state() PCI/ASPM: Save L1 PM Substates Capability for suspend/resume PCI: hv: Fix ring buffer size calculation PCI: dwc: endpoint: Fix advertised resizable BAR size PCI: cadence: Clear the ARI Capability Next Function Number of the last function PCI: dwc: Strengthen the MSI address allocation logic PCI: brcmstb: Fix broken brcm_pcie_mdio_write() polling PCI: qcom: Add X1E80100 PCIe support dt-bindings: PCI: qcom: Document the X1E80100 PCIe Controller PCI: qcom: Enable BDF to SID translation properly PCI/AER: Generalize TLP Header Log reading PCI/AER: Use explicit register size for PCI_ERR_CAP PCI: qcom: Disable ASPM L0s for sc8280xp, sa8540p and sa8295p dt-bindings: PCI: qcom: Do not require 'msi-map-mask' dt-bindings: PCI: qcom: Allow 'required-opps' PCI/AER: Block runtime suspend when handling errors PCI/ASPM: Move pci_save_ltr_state() to aspm.c PCI/ASPM: Always build aspm.c ...
2024-03-10PCI: dwc: endpoint: Fix advertised resizable BAR sizeNiklas Cassel
The commit message in commit fc9a77040b04 ("PCI: designware-ep: Configure Resizable BAR cap to advertise the smallest size") claims that it modifies the Resizable BAR capability to only advertise support for 1 MB size BARs. However, the commit writes all zeroes to PCI_REBAR_CAP (the register which contains the possible BAR sizes that a BAR be resized to). According to the spec, it is illegal to not have a bit set in PCI_REBAR_CAP, and 1 MB is the smallest size allowed. Set bit 4 in PCI_REBAR_CAP, so that we actually advertise support for a 1 MB BAR size. Before: Capabilities: [2e8 v1] Physical Resizable BAR BAR 0: current size: 1MB BAR 1: current size: 1MB BAR 2: current size: 1MB BAR 3: current size: 1MB BAR 4: current size: 1MB BAR 5: current size: 1MB After: Capabilities: [2e8 v1] Physical Resizable BAR BAR 0: current size: 1MB, supported: 1MB BAR 1: current size: 1MB, supported: 1MB BAR 2: current size: 1MB, supported: 1MB BAR 3: current size: 1MB, supported: 1MB BAR 4: current size: 1MB, supported: 1MB BAR 5: current size: 1MB, supported: 1MB Fixes: fc9a77040b04 ("PCI: designware-ep: Configure Resizable BAR cap to advertise the smallest size") Link: https://lore.kernel.org/linux-pci/20240307111520.3303774-1-cassel@kernel.org Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Cc: <stable@vger.kernel.org> # 5.2
2024-02-07PCI: dwc: Clean up dw_pcie_ep_raise_msi_irq() alignmentDan Carpenter
I recently changed the alignment code in dw_pcie_ep_raise_msix_irq(). The code in dw_pcie_ep_raise_msi_irq() is similar, so update it to match, just for consistency. (No effect on runtime, just a cleanup). Link: https://lore.kernel.org/r/184097e0-c728-42c7-9e8a-556bd33fb612@moroto.mountain Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Niklas Cassel <cassel@kernel.org> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-02-07PCI: dwc: Fix a 64bit bug in dw_pcie_ep_raise_msix_irq()Dan Carpenter
The "msg_addr" variable is u64. However, the "aligned_offset" is an unsigned int. This means that when the code does: msg_addr &= ~aligned_offset; it will unintentionally zero out the high 32 bits. Use ALIGN_DOWN() to do the alignment instead. Fixes: 2217fffcd63f ("PCI: dwc: endpoint: Fix dw_pcie_ep_raise_msix_irq() alignment support") Link: https://lore.kernel.org/r/af59c7ad-ab93-40f7-ad4a-7ac0b14d37f5@moroto.mountain Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Niklas Cassel <cassel@kernel.org> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Cc: <stable@vger.kernel.org>
generated by cgit (git 2.34.1) at 2025-07-15 12:23:04 +0000