kernel/linux.git/include/linux/pci-epc.h, branch v6.19.11

PCI: endpoint: Add BAR subrange mapping support

2026-02-26T23:01:10+00:00

[ Upstream commit 31fb95400451040050361e22ff480476964280f0 ] Some endpoint platforms have only a small number of usable BARs. At the same time, EPF drivers (e.g. vNTB) may need multiple independent inbound regions (control/scratchpad, one or more memory windows, and optionally MSI or other feature-related regions). Subrange mapping allows these to share a single BAR without consuming additional BARs that may not be available, or forcing a fragile layout by aggressively packing into a single contiguous memory range. Extend the PCI endpoint core to support mapping subranges within a BAR. Add an optional 'submap' field in struct pci_epf_bar so an endpoint function driver can request inbound mappings that fully cover the BAR. Introduce a new EPC feature bit, subrange_mapping, and reject submap requests from pci_epc_set_bar() unless the controller advertises both subrange_mapping and dynamic_inbound_mapping features. The submap array describes the complete BAR layout (no overlaps and no gaps are allowed to avoid exposing untranslated address ranges). This provides the generic infrastructure needed to map multiple logical regions into a single BAR at different offsets, without assuming a controller-specific inbound address translation mechanism. Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Reviewed-by: Niklas Cassel Link: https://patch.msgid.link/20260124145012.2794108-3-den@valinux.co.jp Stable-dep-of: 72cb5ed2a5c6 ("PCI: dwc: ep: Add per-PF BAR and inbound ATU mapping support") Signed-off-by: Sasha Levin

PCI: endpoint: Add dynamic_inbound_mapping EPC feature

2026-02-26T23:01:10+00:00

[ Upstream commit 06a81c5940e46cc7bddee28f16bdd29a12a76344 ] Introduce a new EPC feature bit (dynamic_inbound_mapping) that indicates whether an Endpoint Controller can update the inbound address translation for a BAR without requiring the EPF driver to clear/reset the BAR first. Endpoint Function drivers (e.g. vNTB) can use this information to decide whether it really is safe to call pci_epc_set_bar() multiple times to update inbound mappings for the BAR. Suggested-by: Niklas Cassel Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Reviewed-by: Niklas Cassel Reviewed-by: Frank Li Link: https://patch.msgid.link/20260124145012.2794108-2-den@valinux.co.jp Stable-dep-of: 72cb5ed2a5c6 ("PCI: dwc: ep: Add per-PF BAR and inbound ATU mapping support") Signed-off-by: Sasha Levin

PCI: endpoint: Align pci_epc_set_msix(), pci_epc_ops::set_msix() nr_irqs encoding

2025-05-28T21:47:56+00:00

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 Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Cc: stable+noautosel@kernel.org # this is simply a cleanup Link: https://patch.msgid.link/20250514074313.283156-14-cassel@kernel.org

PCI: endpoint: Align pci_epc_set_msi(), pci_epc_ops::set_msi() nr_irqs encoding

2025-05-28T21:47:56+00:00

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 Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Cc: stable+noautosel@kernel.org # this is simply a cleanup Link: https://patch.msgid.link/20250514074313.283156-13-cassel@kernel.org

Merge branch 'pci/endpoint-test'

2025-03-27T18:14:46+00:00

- Fix endpoint BAR testing so the test can skip disabled BARs instead of reporting them as failures (Niklas Cassel) - Verify that pci_endpoint interrupt tests set the correct IRQ type (Kunihiko Hayashi) - Fix interpretation of pci_endpoint_test_bars_read_bar() error returns (Niklas Cassel) - Fix potential string truncation in pci_endpoint_test_probe() (Niklas Cassel) - Increase endpoint test BAR size variable to accommodate BARs larger than INT_MAX (Niklas Cassel) - Release IRQs to avoid leak in pci_endpoint interrupt tests (Kunihiko Hayashi) - Log the correct IRQ type when pci_endpoint IRQ request test fails (Kunihiko Hayashi) - Remove pci_endpoint_test irq_type and no_msi globals; instead use test->irq_type (Kunihiko Hayashi) - Remove unnecessary use of managed IRQ functions in pci_endpoint_test (Kunihiko Hayashi) - Add and use IRQ_TYPE_* defines in pci_endpoint_test (Niklas Cassel) - Add struct pci_epc_features.intx_capable and note that RK3568 and RK3588 can't raise INTx interrupts (Niklas Cassel) - Expose supported IRQ types in CAPS so pci_endpoint_test can set appropriate type (Niklas Cassel) - Add PCITEST_IRQ_TYPE_AUTO to pci_endpoint_test for cases where the IRQ type doesn't matter (Niklas Cassel) * pci/endpoint-test: misc: pci_endpoint_test: Add support for PCITEST_IRQ_TYPE_AUTO PCI: endpoint: pci-epf-test: Expose supported IRQ types in CAPS register PCI: dw-rockchip: Endpoint mode cannot raise INTx interrupts PCI: endpoint: Add intx_capable to epc_features struct selftests: pci_endpoint: Use IRQ_TYPE_* defines from UAPI header misc: pci_endpoint_test: Use IRQ_TYPE_* defines from UAPI header PCI: endpoint: pcitest: Add IRQ_TYPE_* defines to UAPI header misc: pci_endpoint_test: Do not use managed IRQ functions misc: pci_endpoint_test: Remove global 'irq_type' and 'no_msi' misc: pci_endpoint_test: Fix 'irq_type' to convey the correct type misc: pci_endpoint_test: Fix displaying 'irq_type' after 'request_irq' error misc: pci_endpoint_test: Avoid issue of interrupts remaining after request_irq error misc: pci_endpoint_test: Handle BAR sizes larger than INT_MAX misc: pci_endpoint_test: Give disabled BARs a distinct error code misc: pci_endpoint_test: Fix potential truncation in pci_endpoint_test_probe() misc: pci_endpoint_test: Fix pci_endpoint_test_bars_read_bar() error handling selftests: pci_endpoint: Add GET_IRQTYPE checks to each interrupt test selftests: pci_endpoint: Skip disabled BARs

PCI: endpoint: Add intx_capable to epc_features struct

2025-03-26T06:09:38+00:00

In struct pci_epc_features, an EPC driver can already specify if they support MSI (by setting msi_capable) and MSI-X (by setting msix_capable). Thus, for consistency, allow an EPC driver to specify if it supports INTx interrupts as well (by setting intx_capable). Since this struct is zero initialized, EPC drivers that want to claim INTx support will need to set intx_capable to true. Signed-off-by: Niklas Cassel [kwilczynski: add missing kernel-doc for "intx_capable"] Signed-off-by: Krzysztof Wilczyński Link: https://lore.kernel.org/r/20250310111016.859445-13-cassel@kernel.org

PCI: endpoint: Remove unused devm_pci_epc_destroy()

2025-03-08T14:47:31+00:00

The static function devm_pci_epc_match() is only invoked within the devm_pci_epc_destroy(). However, since it was initially introduced, this new API has had no callers. Thus, remove both the unused API and the static function. Reviewed-by: Manivannan Sadhasivam Signed-off-by: Zijun Hu Link: https://lore.kernel.org/r/20250217-remove_api-v2-1-b169c9117045@quicinc.com Signed-off-by: Manivannan Sadhasivam [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński

PCI: endpoint: Add pci_epc_bar_size_to_rebar_cap()

2025-03-08T14:43:05+00:00

Add a helper function to convert a size to the representation used by the Resizable BAR Capability Register. Signed-off-by: Niklas Cassel Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20250131182949.465530-11-cassel@kernel.org [mani: squashed the change that added PCIe spec reference to comments from https://lore.kernel.org/linux-pci/20250219171454.2903059-2-cassel@kernel.org] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Krzysztof Wilczyński

PCI: endpoint: Allow EPF drivers to configure the size of Resizable BARs

2025-03-08T14:43:02+00:00

A resizable BAR is different from a normal BAR in a few ways: - The minimum size of a resizable BAR is 1 MB. - Each BAR that is resizable has a Capability and Control register in the Resizable BAR Capability structure. These registers contain the supported sizes and the currently selected size of a resizable BAR. The supported sizes is a bitmap of the supported sizes. The selected size is a single value that is equal to one of the supported sizes. A resizable BAR thus has to be configured differently than a BAR_PROGRAMMABLE BAR, which usually sets the BAR size/mask in a vendor specific way. The PCI endpoint framework currently does not support resizable BARs. Add a BAR type BAR_RESIZABLE, so that an EPC driver can support resizable BARs properly. 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. Signed-off-by: Niklas Cassel Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20250131182949.465530-10-cassel@kernel.org Signed-off-by: Manivannan Sadhasivam [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński

PCI: endpoint: Fix pci_epc_map map_size kerneldoc string

2024-11-18T17:18:21+00:00

Because some endpoint controllers have requirements on the alignment of the controller physical memory address that must be used to map a RC PCI address region, the map PCI start address is not necessarily the desired PCI base address to be mapped. This can result in map_pci_addr being lower than pci_addr as documented. This results in map_size covering the range map_pci_addr..pci_addr+pci_size. The old text had the pci_addr twice instead of map_pci_addr..pci_addr, so replace the erroneous kerneldoc string to reflect the actual range. Link: https://lore.kernel.org/r/20241114161032.3046202-1-rick.wertenbroek@gmail.com Signed-off-by: Rick Wertenbroek Signed-off-by: Krzysztof Wilczyński