* [PATCH v10 1/8] PCI: endpoint: Add dynamic_inbound_mapping EPC feature
2026-01-24 14:50 [PATCH v10 0/8] PCI: endpoint: BAR subrange mapping support Koichiro Den
@ 2026-01-24 14:50 ` Koichiro Den
2026-01-24 14:50 ` [PATCH v10 2/8] PCI: endpoint: Add BAR subrange mapping support Koichiro Den
` (7 subsequent siblings)
8 siblings, 0 replies; 19+ messages in thread
From: Koichiro Den @ 2026-01-24 14:50 UTC (permalink / raw)
To: jingoohan1, mani, lpieralisi, kwilczynski, robh, bhelgaas, cassel,
Frank.Li
Cc: vigneshr, s-vadapalli, hongxing.zhu, l.stach, shawnguo, s.hauer,
kernel, festevam, minghuan.Lian, mingkai.hu, roy.zang,
jesper.nilsson, heiko, srikanth.thokala, marek.vasut+renesas,
yoshihiro.shimoda.uh, geert+renesas, magnus.damm, christian.bruel,
mcoquelin.stm32, alexandre.torgue, thierry.reding, jonathanh,
hayashi.kunihiko, mhiramat, kishon, jirislaby, rongqianfeng,
18255117159, shawn.lin, nicolas.frattaroli, linux.amoon, vidyas,
shuah, linux-omap, linux-pci, linux-arm-kernel, linux-kernel, imx,
linuxppc-dev, linux-arm-kernel, linux-rockchip, linux-arm-msm,
linux-renesas-soc, linux-stm32, linux-tegra, linux-kselftest
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 <cassel@kernel.org>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Koichiro Den <den@valinux.co.jp>
---
include/linux/pci-epc.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
index 4286bfdbfdfa..4c8516756c56 100644
--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -223,6 +223,10 @@ struct pci_epc_bar_desc {
/**
* struct pci_epc_features - features supported by a EPC device per function
* @linkup_notifier: indicate if the EPC device can notify EPF driver on link up
+ * @dynamic_inbound_mapping: indicate if the EPC device supports updating
+ * inbound mappings for an already configured BAR
+ * (i.e. allow calling pci_epc_set_bar() again
+ * without first calling pci_epc_clear_bar())
* @msi_capable: indicate if the endpoint function has MSI capability
* @msix_capable: indicate if the endpoint function has MSI-X capability
* @intx_capable: indicate if the endpoint can raise INTx interrupts
@@ -231,6 +235,7 @@ struct pci_epc_bar_desc {
*/
struct pci_epc_features {
unsigned int linkup_notifier : 1;
+ unsigned int dynamic_inbound_mapping : 1;
unsigned int msi_capable : 1;
unsigned int msix_capable : 1;
unsigned int intx_capable : 1;
--
2.51.0
^ permalink raw reply related [flat|nested] 19+ messages in thread* [PATCH v10 2/8] PCI: endpoint: Add BAR subrange mapping support
2026-01-24 14:50 [PATCH v10 0/8] PCI: endpoint: BAR subrange mapping support Koichiro Den
2026-01-24 14:50 ` [PATCH v10 1/8] PCI: endpoint: Add dynamic_inbound_mapping EPC feature Koichiro Den
@ 2026-01-24 14:50 ` Koichiro Den
2026-01-24 14:50 ` [PATCH v10 3/8] PCI: dwc: Advertise dynamic inbound " Koichiro Den
` (6 subsequent siblings)
8 siblings, 0 replies; 19+ messages in thread
From: Koichiro Den @ 2026-01-24 14:50 UTC (permalink / raw)
To: jingoohan1, mani, lpieralisi, kwilczynski, robh, bhelgaas, cassel,
Frank.Li
Cc: vigneshr, s-vadapalli, hongxing.zhu, l.stach, shawnguo, s.hauer,
kernel, festevam, minghuan.Lian, mingkai.hu, roy.zang,
jesper.nilsson, heiko, srikanth.thokala, marek.vasut+renesas,
yoshihiro.shimoda.uh, geert+renesas, magnus.damm, christian.bruel,
mcoquelin.stm32, alexandre.torgue, thierry.reding, jonathanh,
hayashi.kunihiko, mhiramat, kishon, jirislaby, rongqianfeng,
18255117159, shawn.lin, nicolas.frattaroli, linux.amoon, vidyas,
shuah, linux-omap, linux-pci, linux-arm-kernel, linux-kernel, imx,
linuxppc-dev, linux-arm-kernel, linux-rockchip, linux-arm-msm,
linux-renesas-soc, linux-stm32, linux-tegra, linux-kselftest
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.
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Koichiro Den <den@valinux.co.jp>
---
drivers/pci/endpoint/pci-epc-core.c | 8 ++++++++
include/linux/pci-epc.h | 4 ++++
include/linux/pci-epf.h | 23 +++++++++++++++++++++++
3 files changed, 35 insertions(+)
diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
index ca7f19cc973a..068155819c57 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -596,6 +596,14 @@ int pci_epc_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
if (!epc_features)
return -EINVAL;
+ if (epf_bar->num_submap && !epf_bar->submap)
+ return -EINVAL;
+
+ if (epf_bar->num_submap &&
+ !(epc_features->dynamic_inbound_mapping &&
+ epc_features->subrange_mapping))
+ return -EINVAL;
+
if (epc_features->bar[bar].type == BAR_RESIZABLE &&
(epf_bar->size < SZ_1M || (u64)epf_bar->size > (SZ_128G * 1024)))
return -EINVAL;
diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
index 4c8516756c56..c021c7af175f 100644
--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -227,6 +227,9 @@ struct pci_epc_bar_desc {
* inbound mappings for an already configured BAR
* (i.e. allow calling pci_epc_set_bar() again
* without first calling pci_epc_clear_bar())
+ * @subrange_mapping: indicate if the EPC device can map inbound subranges for a
+ * BAR. This feature depends on @dynamic_inbound_mapping
+ * feature.
* @msi_capable: indicate if the endpoint function has MSI capability
* @msix_capable: indicate if the endpoint function has MSI-X capability
* @intx_capable: indicate if the endpoint can raise INTx interrupts
@@ -236,6 +239,7 @@ struct pci_epc_bar_desc {
struct pci_epc_features {
unsigned int linkup_notifier : 1;
unsigned int dynamic_inbound_mapping : 1;
+ unsigned int subrange_mapping : 1;
unsigned int msi_capable : 1;
unsigned int msix_capable : 1;
unsigned int intx_capable : 1;
diff --git a/include/linux/pci-epf.h b/include/linux/pci-epf.h
index 48f68c4dcfa5..7737a7c03260 100644
--- a/include/linux/pci-epf.h
+++ b/include/linux/pci-epf.h
@@ -110,6 +110,22 @@ struct pci_epf_driver {
#define to_pci_epf_driver(drv) container_of_const((drv), struct pci_epf_driver, driver)
+/**
+ * struct pci_epf_bar_submap - BAR subrange for inbound mapping
+ * @phys_addr: target physical/DMA address for this subrange
+ * @size: the size of the subrange to be mapped
+ *
+ * When pci_epf_bar.num_submap is >0, pci_epf_bar.submap describes the
+ * complete BAR layout. This allows an EPC driver to program multiple
+ * inbound translation windows for a single BAR when supported by the
+ * controller. The array order defines the BAR layout (submap[0] at offset
+ * 0, and each immediately follows the previous one).
+ */
+struct pci_epf_bar_submap {
+ dma_addr_t phys_addr;
+ size_t size;
+};
+
/**
* struct pci_epf_bar - represents the BAR of EPF device
* @phys_addr: physical address that should be mapped to the BAR
@@ -119,6 +135,9 @@ struct pci_epf_driver {
* requirement
* @barno: BAR number
* @flags: flags that are set for the BAR
+ * @num_submap: number of entries in @submap
+ * @submap: array of subrange descriptors allocated by the caller. See
+ * struct pci_epf_bar_submap for the semantics in detail.
*/
struct pci_epf_bar {
dma_addr_t phys_addr;
@@ -127,6 +146,10 @@ struct pci_epf_bar {
size_t mem_size;
enum pci_barno barno;
int flags;
+
+ /* Optional sub-range mapping */
+ unsigned int num_submap;
+ struct pci_epf_bar_submap *submap;
};
/**
--
2.51.0
^ permalink raw reply related [flat|nested] 19+ messages in thread* [PATCH v10 3/8] PCI: dwc: Advertise dynamic inbound mapping support
2026-01-24 14:50 [PATCH v10 0/8] PCI: endpoint: BAR subrange mapping support Koichiro Den
2026-01-24 14:50 ` [PATCH v10 1/8] PCI: endpoint: Add dynamic_inbound_mapping EPC feature Koichiro Den
2026-01-24 14:50 ` [PATCH v10 2/8] PCI: endpoint: Add BAR subrange mapping support Koichiro Den
@ 2026-01-24 14:50 ` Koichiro Den
2026-03-13 15:59 ` Christian Bruel
2026-01-24 14:50 ` [PATCH v10 4/8] PCI: dwc: ep: Support BAR subrange inbound mapping via Address Match Mode iATU Koichiro Den
` (5 subsequent siblings)
8 siblings, 1 reply; 19+ messages in thread
From: Koichiro Den @ 2026-01-24 14:50 UTC (permalink / raw)
To: jingoohan1, mani, lpieralisi, kwilczynski, robh, bhelgaas, cassel,
Frank.Li
Cc: vigneshr, s-vadapalli, hongxing.zhu, l.stach, shawnguo, s.hauer,
kernel, festevam, minghuan.Lian, mingkai.hu, roy.zang,
jesper.nilsson, heiko, srikanth.thokala, marek.vasut+renesas,
yoshihiro.shimoda.uh, geert+renesas, magnus.damm, christian.bruel,
mcoquelin.stm32, alexandre.torgue, thierry.reding, jonathanh,
hayashi.kunihiko, mhiramat, kishon, jirislaby, rongqianfeng,
18255117159, shawn.lin, nicolas.frattaroli, linux.amoon, vidyas,
shuah, linux-omap, linux-pci, linux-arm-kernel, linux-kernel, imx,
linuxppc-dev, linux-arm-kernel, linux-rockchip, linux-arm-msm,
linux-renesas-soc, linux-stm32, linux-tegra, linux-kselftest
The DesignWare EP core has supported updating the inbound iATU mapping
for an already configured BAR (i.e. allowing pci_epc_set_bar() to be
called again without a prior pci_epc_clear_bar()) since
commit 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update
inbound map address").
Now that this capability is exposed via the dynamic_inbound_mapping EPC
feature bit, set it for DWC-based EP glue drivers using a common
initializer macro to avoid duplicating the same flag in each driver.
Note that pci-layerscape-ep.c is untouched. It currently constructs the
feature struct dynamically in ls_pcie_ep_init(). Once converted to a
static feature definition, it will use DWC_EPC_COMMON_FEATURES as well.
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Koichiro Den <den@valinux.co.jp>
---
drivers/pci/controller/dwc/pci-dra7xx.c | 1 +
drivers/pci/controller/dwc/pci-imx6.c | 3 +++
drivers/pci/controller/dwc/pci-keystone.c | 1 +
drivers/pci/controller/dwc/pcie-artpec6.c | 1 +
drivers/pci/controller/dwc/pcie-designware-plat.c | 1 +
drivers/pci/controller/dwc/pcie-designware.h | 3 +++
drivers/pci/controller/dwc/pcie-dw-rockchip.c | 2 ++
drivers/pci/controller/dwc/pcie-keembay.c | 1 +
drivers/pci/controller/dwc/pcie-qcom-ep.c | 1 +
drivers/pci/controller/dwc/pcie-rcar-gen4.c | 1 +
drivers/pci/controller/dwc/pcie-stm32-ep.c | 1 +
drivers/pci/controller/dwc/pcie-tegra194.c | 1 +
drivers/pci/controller/dwc/pcie-uniphier-ep.c | 2 ++
13 files changed, 19 insertions(+)
diff --git a/drivers/pci/controller/dwc/pci-dra7xx.c b/drivers/pci/controller/dwc/pci-dra7xx.c
index 01cfd9aeb0b8..d5d26229063f 100644
--- a/drivers/pci/controller/dwc/pci-dra7xx.c
+++ b/drivers/pci/controller/dwc/pci-dra7xx.c
@@ -424,6 +424,7 @@ static int dra7xx_pcie_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
}
static const struct pci_epc_features dra7xx_pcie_epc_features = {
+ DWC_EPC_COMMON_FEATURES,
.linkup_notifier = true,
.msi_capable = true,
};
diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index dfe814469993..06f45e009d7d 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -1388,6 +1388,7 @@ static int imx_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
}
static const struct pci_epc_features imx8m_pcie_epc_features = {
+ DWC_EPC_COMMON_FEATURES,
.msi_capable = true,
.bar[BAR_1] = { .type = BAR_RESERVED, },
.bar[BAR_3] = { .type = BAR_RESERVED, },
@@ -1397,6 +1398,7 @@ static const struct pci_epc_features imx8m_pcie_epc_features = {
};
static const struct pci_epc_features imx8q_pcie_epc_features = {
+ DWC_EPC_COMMON_FEATURES,
.msi_capable = true,
.bar[BAR_1] = { .type = BAR_RESERVED, },
.bar[BAR_3] = { .type = BAR_RESERVED, },
@@ -1417,6 +1419,7 @@ static const struct pci_epc_features imx8q_pcie_epc_features = {
* BAR5 | Enable | 32-bit | 64 KB | Programmable Size
*/
static const struct pci_epc_features imx95_pcie_epc_features = {
+ DWC_EPC_COMMON_FEATURES,
.msi_capable = true,
.bar[BAR_1] = { .type = BAR_FIXED, .fixed_size = SZ_64K, },
.align = SZ_4K,
diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c
index f86d9111f863..20fa4dadb82a 100644
--- a/drivers/pci/controller/dwc/pci-keystone.c
+++ b/drivers/pci/controller/dwc/pci-keystone.c
@@ -930,6 +930,7 @@ static int ks_pcie_am654_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
}
static const struct pci_epc_features ks_pcie_am654_epc_features = {
+ DWC_EPC_COMMON_FEATURES,
.msi_capable = true,
.msix_capable = true,
.bar[BAR_0] = { .type = BAR_RESERVED, },
diff --git a/drivers/pci/controller/dwc/pcie-artpec6.c b/drivers/pci/controller/dwc/pcie-artpec6.c
index f4a136ee2daf..e994b75986c3 100644
--- a/drivers/pci/controller/dwc/pcie-artpec6.c
+++ b/drivers/pci/controller/dwc/pcie-artpec6.c
@@ -370,6 +370,7 @@ static int artpec6_pcie_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
}
static const struct pci_epc_features artpec6_pcie_epc_features = {
+ DWC_EPC_COMMON_FEATURES,
.msi_capable = true,
};
diff --git a/drivers/pci/controller/dwc/pcie-designware-plat.c b/drivers/pci/controller/dwc/pcie-designware-plat.c
index 12f41886c65d..8530746ec5cb 100644
--- a/drivers/pci/controller/dwc/pcie-designware-plat.c
+++ b/drivers/pci/controller/dwc/pcie-designware-plat.c
@@ -61,6 +61,7 @@ static int dw_plat_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
}
static const struct pci_epc_features dw_plat_pcie_epc_features = {
+ DWC_EPC_COMMON_FEATURES,
.msi_capable = true,
.msix_capable = true,
};
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index c3301b3aedb7..7ca9d0f6b7f2 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -305,6 +305,9 @@
/* Default eDMA LLP memory size */
#define DMA_LLP_MEM_SIZE PAGE_SIZE
+/* Common struct pci_epc_feature bits among DWC EP glue drivers */
+#define DWC_EPC_COMMON_FEATURES .dynamic_inbound_mapping = true
+
struct dw_pcie;
struct dw_pcie_rp;
struct dw_pcie_ep;
diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
index 77c4e6a4ddea..03ad8c242366 100644
--- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
+++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
@@ -382,6 +382,7 @@ static int rockchip_pcie_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
}
static const struct pci_epc_features rockchip_pcie_epc_features_rk3568 = {
+ DWC_EPC_COMMON_FEATURES,
.linkup_notifier = true,
.msi_capable = true,
.msix_capable = true,
@@ -402,6 +403,7 @@ static const struct pci_epc_features rockchip_pcie_epc_features_rk3568 = {
* BARs) would be overwritten, resulting in (all other BARs) no longer working.
*/
static const struct pci_epc_features rockchip_pcie_epc_features_rk3588 = {
+ DWC_EPC_COMMON_FEATURES,
.linkup_notifier = true,
.msi_capable = true,
.msix_capable = true,
diff --git a/drivers/pci/controller/dwc/pcie-keembay.c b/drivers/pci/controller/dwc/pcie-keembay.c
index 60e74ac782af..2666a9c3d67e 100644
--- a/drivers/pci/controller/dwc/pcie-keembay.c
+++ b/drivers/pci/controller/dwc/pcie-keembay.c
@@ -309,6 +309,7 @@ static int keembay_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
}
static const struct pci_epc_features keembay_pcie_epc_features = {
+ DWC_EPC_COMMON_FEATURES,
.msi_capable = true,
.msix_capable = true,
.bar[BAR_0] = { .only_64bit = true, },
diff --git a/drivers/pci/controller/dwc/pcie-qcom-ep.c b/drivers/pci/controller/dwc/pcie-qcom-ep.c
index f1bc0ac81a92..5e990c7a5879 100644
--- a/drivers/pci/controller/dwc/pcie-qcom-ep.c
+++ b/drivers/pci/controller/dwc/pcie-qcom-ep.c
@@ -820,6 +820,7 @@ static void qcom_pcie_ep_init_debugfs(struct qcom_pcie_ep *pcie_ep)
}
static const struct pci_epc_features qcom_pcie_epc_features = {
+ DWC_EPC_COMMON_FEATURES,
.linkup_notifier = true,
.msi_capable = true,
.align = SZ_4K,
diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
index 80778917d2dd..a6912e85e4dd 100644
--- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
+++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
@@ -420,6 +420,7 @@ static int rcar_gen4_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
}
static const struct pci_epc_features rcar_gen4_pcie_epc_features = {
+ DWC_EPC_COMMON_FEATURES,
.msi_capable = true,
.bar[BAR_1] = { .type = BAR_RESERVED, },
.bar[BAR_3] = { .type = BAR_RESERVED, },
diff --git a/drivers/pci/controller/dwc/pcie-stm32-ep.c b/drivers/pci/controller/dwc/pcie-stm32-ep.c
index 2cecf32d2b0f..c1944b40ce02 100644
--- a/drivers/pci/controller/dwc/pcie-stm32-ep.c
+++ b/drivers/pci/controller/dwc/pcie-stm32-ep.c
@@ -70,6 +70,7 @@ static int stm32_pcie_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
}
static const struct pci_epc_features stm32_pcie_epc_features = {
+ DWC_EPC_COMMON_FEATURES,
.msi_capable = true,
.align = SZ_64K,
};
diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
index 0ddeef70726d..06571d806ab3 100644
--- a/drivers/pci/controller/dwc/pcie-tegra194.c
+++ b/drivers/pci/controller/dwc/pcie-tegra194.c
@@ -1988,6 +1988,7 @@ static int tegra_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
}
static const struct pci_epc_features tegra_pcie_epc_features = {
+ DWC_EPC_COMMON_FEATURES,
.linkup_notifier = true,
.msi_capable = true,
.bar[BAR_0] = { .type = BAR_FIXED, .fixed_size = SZ_1M,
diff --git a/drivers/pci/controller/dwc/pcie-uniphier-ep.c b/drivers/pci/controller/dwc/pcie-uniphier-ep.c
index d6e73811216e..d52753060970 100644
--- a/drivers/pci/controller/dwc/pcie-uniphier-ep.c
+++ b/drivers/pci/controller/dwc/pcie-uniphier-ep.c
@@ -420,6 +420,7 @@ static const struct uniphier_pcie_ep_soc_data uniphier_pro5_data = {
.init = uniphier_pcie_pro5_init_ep,
.wait = NULL,
.features = {
+ DWC_EPC_COMMON_FEATURES,
.linkup_notifier = false,
.msi_capable = true,
.msix_capable = false,
@@ -438,6 +439,7 @@ static const struct uniphier_pcie_ep_soc_data uniphier_nx1_data = {
.init = uniphier_pcie_nx1_init_ep,
.wait = uniphier_pcie_nx1_wait_ep,
.features = {
+ DWC_EPC_COMMON_FEATURES,
.linkup_notifier = false,
.msi_capable = true,
.msix_capable = false,
--
2.51.0
^ permalink raw reply related [flat|nested] 19+ messages in thread* Re: [PATCH v10 3/8] PCI: dwc: Advertise dynamic inbound mapping support
2026-01-24 14:50 ` [PATCH v10 3/8] PCI: dwc: Advertise dynamic inbound " Koichiro Den
@ 2026-03-13 15:59 ` Christian Bruel
2026-03-13 18:18 ` Bjorn Helgaas
2026-03-14 4:33 ` Koichiro Den
0 siblings, 2 replies; 19+ messages in thread
From: Christian Bruel @ 2026-03-13 15:59 UTC (permalink / raw)
To: Koichiro Den, jingoohan1, mani, lpieralisi, kwilczynski, robh,
bhelgaas, cassel, Frank.Li
Cc: vigneshr, s-vadapalli, hongxing.zhu, l.stach, shawnguo, s.hauer,
kernel, festevam, minghuan.Lian, mingkai.hu, roy.zang,
jesper.nilsson, heiko, srikanth.thokala, marek.vasut+renesas,
yoshihiro.shimoda.uh, geert+renesas, magnus.damm, mcoquelin.stm32,
alexandre.torgue, thierry.reding, jonathanh, hayashi.kunihiko,
mhiramat, kishon, jirislaby, rongqianfeng, 18255117159, shawn.lin,
nicolas.frattaroli, linux.amoon, vidyas, shuah, linux-omap,
linux-pci, linux-arm-kernel, linux-kernel, imx, linuxppc-dev,
linux-arm-kernel, linux-rockchip, linux-arm-msm,
linux-renesas-soc, linux-stm32, linux-tegra, linux-kselftest
Hello,
While testing after this series, I encountered regressions on the
STM32MP2, which I am unsure how to fix. The failures depend on the order
in which the tests are run.
The STM32 ATU has 4 inbound entries. After enumeration, the first 4 ATU
entries are allocated within ib_window_map.
On the first run of ./pci_endpoint_test -v BAR3(for example),
SUBRRANGE_SETUP calls dw_pcie_ep_ib_atu_addr(), which frees only one ATU
entry (BAR3), because we were in the bar_to_atu case, for the first
submap but fails to allocate the second submap. So the test FAILs.
On the second run with a different BAR, SUBRRANGE_SETUP test calls
dw_pcie_ep_ib_atu_addr() again, freeing the required ATU entry (BAR1)
and successfully using the second ATU entry (3), which was left
unallocated by the first test. then now the test PASSes
Therefore, the first invocation of ./pci_endpoint_test on any BAR always
fails. Other invocations are fine because the first one has left the
missing necessary ATU entry free. Whatever initial BAR number is used
I am unsure how to fix this. Always freeing all BARs before calling
set_bar() in the epf-test seems overkill, but safe.
I am also considering modifying dw_pcie_ep_clear_ib_maps() to clear N
num_submap entries even if ib_atu_indexes was not used yet, since only
the full BAR is used during the first invocation from bar_to_atu. But
the question is which ATU entry to select ? BAR+1 ?. This seems empirical.
I am not bothered by test failures due to an insufficient number of BARs
(this is already the case for BAR5,6), but the fact that the failures
depend on the test order is frustrating and show a regression.
But I'm not satisfied with either of the 2 possible fixes mentioned above.
Do you have any other thought ?
thank you
Christian
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v10 3/8] PCI: dwc: Advertise dynamic inbound mapping support
2026-03-13 15:59 ` Christian Bruel
@ 2026-03-13 18:18 ` Bjorn Helgaas
2026-03-16 12:26 ` Christian Bruel
2026-03-14 4:33 ` Koichiro Den
1 sibling, 1 reply; 19+ messages in thread
From: Bjorn Helgaas @ 2026-03-13 18:18 UTC (permalink / raw)
To: Christian Bruel
Cc: Koichiro Den, jingoohan1, mani, lpieralisi, kwilczynski, robh,
bhelgaas, cassel, Frank.Li, vigneshr, s-vadapalli, hongxing.zhu,
l.stach, shawnguo, s.hauer, kernel, festevam, minghuan.Lian,
mingkai.hu, roy.zang, jesper.nilsson, heiko, srikanth.thokala,
marek.vasut+renesas, yoshihiro.shimoda.uh, geert+renesas,
magnus.damm, mcoquelin.stm32, alexandre.torgue, thierry.reding,
jonathanh, hayashi.kunihiko, mhiramat, kishon, jirislaby,
rongqianfeng, 18255117159, shawn.lin, nicolas.frattaroli,
linux.amoon, vidyas, shuah, linux-omap, linux-pci,
linux-arm-kernel, linux-kernel, imx, linuxppc-dev,
linux-arm-kernel, linux-rockchip, linux-arm-msm,
linux-renesas-soc, linux-stm32, linux-tegra, linux-kselftest
On Fri, Mar 13, 2026 at 04:59:26PM +0100, Christian Bruel wrote:
> Hello,
>
> While testing after this series, I encountered regressions on the STM32MP2,
> which I am unsure how to fix. The failures depend on the order in which the
> tests are run.
c0f1506f6354 ("PCI: dwc: Advertise dynamic inbound mapping support")
appeared in v7.0-rc1, so apparently we added a regression in v7.0? Do
we need to revert this?
> The STM32 ATU has 4 inbound entries. After enumeration, the first 4 ATU
> entries are allocated within ib_window_map.
>
> On the first run of ./pci_endpoint_test -v BAR3(for example),
> SUBRRANGE_SETUP calls dw_pcie_ep_ib_atu_addr(), which frees only one ATU
> entry (BAR3), because we were in the bar_to_atu case, for the first submap
> but fails to allocate the second submap. So the test FAILs.
>
> On the second run with a different BAR, SUBRRANGE_SETUP test calls
> dw_pcie_ep_ib_atu_addr() again, freeing the required ATU entry (BAR1) and
> successfully using the second ATU entry (3), which was left unallocated by
> the first test. then now the test PASSes
>
> Therefore, the first invocation of ./pci_endpoint_test on any BAR always
> fails. Other invocations are fine because the first one has left the missing
> necessary ATU entry free. Whatever initial BAR number is used
>
> I am unsure how to fix this. Always freeing all BARs before calling
> set_bar() in the epf-test seems overkill, but safe.
> I am also considering modifying dw_pcie_ep_clear_ib_maps() to clear N
> num_submap entries even if ib_atu_indexes was not used yet, since only the
> full BAR is used during the first invocation from bar_to_atu. But the
> question is which ATU entry to select ? BAR+1 ?. This seems empirical.
>
> I am not bothered by test failures due to an insufficient number of BARs
> (this is already the case for BAR5,6), but the fact that the failures depend
> on the test order is frustrating and show a regression.
>
> But I'm not satisfied with either of the 2 possible fixes mentioned above.
>
> Do you have any other thought ?
>
> thank you
>
> Christian
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH v10 3/8] PCI: dwc: Advertise dynamic inbound mapping support
2026-03-13 18:18 ` Bjorn Helgaas
@ 2026-03-16 12:26 ` Christian Bruel
0 siblings, 0 replies; 19+ messages in thread
From: Christian Bruel @ 2026-03-16 12:26 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Koichiro Den, jingoohan1, mani, lpieralisi, kwilczynski, robh,
bhelgaas, cassel, Frank.Li, vigneshr, s-vadapalli, hongxing.zhu,
l.stach, shawnguo, s.hauer, kernel, festevam, minghuan.Lian,
mingkai.hu, roy.zang, jesper.nilsson, heiko, srikanth.thokala,
marek.vasut+renesas, yoshihiro.shimoda.uh, geert+renesas,
magnus.damm, mcoquelin.stm32, alexandre.torgue, thierry.reding,
jonathanh, hayashi.kunihiko, mhiramat, kishon, jirislaby,
rongqianfeng, 18255117159, shawn.lin, nicolas.frattaroli,
linux.amoon, vidyas, shuah, linux-omap, linux-pci,
linux-arm-kernel, linux-kernel, imx, linuxppc-dev,
linux-arm-kernel, linux-rockchip, linux-arm-msm,
linux-renesas-soc, linux-stm32, linux-tegra, linux-kselftest
On 3/13/26 19:18, Bjorn Helgaas wrote:
> On Fri, Mar 13, 2026 at 04:59:26PM +0100, Christian Bruel wrote:
>> Hello,
>>
>> While testing after this series, I encountered regressions on the STM32MP2,
>> which I am unsure how to fix. The failures depend on the order in which the
>> tests are run.
>
> c0f1506f6354 ("PCI: dwc: Advertise dynamic inbound mapping support")
> appeared in v7.0-rc1, so apparently we added a regression in v7.0? Do
> we need to revert this?
With the rollback Koichiro proposed, the regression is now confined to
the EPF bar subrange test, and possibly to platforms that do not have
enough ATU entries (this I am not sure). Let's wait a bit to see if we
can fix it.
Cheers
Christian
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v10 3/8] PCI: dwc: Advertise dynamic inbound mapping support
2026-03-13 15:59 ` Christian Bruel
2026-03-13 18:18 ` Bjorn Helgaas
@ 2026-03-14 4:33 ` Koichiro Den
2026-03-16 12:41 ` Christian Bruel
1 sibling, 1 reply; 19+ messages in thread
From: Koichiro Den @ 2026-03-14 4:33 UTC (permalink / raw)
To: Christian Bruel
Cc: jingoohan1, mani, lpieralisi, kwilczynski, robh, bhelgaas, cassel,
Frank.Li, vigneshr, s-vadapalli, hongxing.zhu, l.stach, shawnguo,
s.hauer, kernel, festevam, minghuan.Lian, mingkai.hu, roy.zang,
jesper.nilsson, heiko, srikanth.thokala, marek.vasut+renesas,
yoshihiro.shimoda.uh, geert+renesas, magnus.damm, mcoquelin.stm32,
alexandre.torgue, thierry.reding, jonathanh, hayashi.kunihiko,
mhiramat, kishon, jirislaby, rongqianfeng, 18255117159, shawn.lin,
nicolas.frattaroli, linux.amoon, vidyas, shuah, linux-omap,
linux-pci, linux-arm-kernel, linux-kernel, imx, linuxppc-dev,
linux-arm-kernel, linux-rockchip, linux-arm-msm,
linux-renesas-soc, linux-stm32, linux-tegra, linux-kselftest
On Fri, Mar 13, 2026 at 04:59:26PM +0100, Christian Bruel wrote:
> Hello,
>
> While testing after this series, I encountered regressions on the STM32MP2,
> which I am unsure how to fix. The failures depend on the order in which the
> tests are run.
>
> The STM32 ATU has 4 inbound entries. After enumeration, the first 4 ATU
> entries are allocated within ib_window_map.
>
> On the first run of ./pci_endpoint_test -v BAR3(for example),
> SUBRRANGE_SETUP calls dw_pcie_ep_ib_atu_addr(), which frees only one ATU
> entry (BAR3), because we were in the bar_to_atu case, for the first submap
> but fails to allocate the second submap. So the test FAILs.
>
> On the second run with a different BAR, SUBRRANGE_SETUP test calls
> dw_pcie_ep_ib_atu_addr() again, freeing the required ATU entry (BAR1) and
> successfully using the second ATU entry (3), which was left unallocated by
> the first test. then now the test PASSes
>
> Therefore, the first invocation of ./pci_endpoint_test on any BAR always
> fails. Other invocations are fine because the first one has left the missing
> necessary ATU entry free. Whatever initial BAR number is used
>
> I am unsure how to fix this. Always freeing all BARs before calling
> set_bar() in the epf-test seems overkill, but safe.
> I am also considering modifying dw_pcie_ep_clear_ib_maps() to clear N
> num_submap entries even if ib_atu_indexes was not used yet, since only the
> full BAR is used during the first invocation from bar_to_atu. But the
> question is which ATU entry to select ? BAR+1 ?. This seems empirical.
>
> I am not bothered by test failures due to an insufficient number of BARs
> (this is already the case for BAR5,6), but the fact that the failures depend
> on the test order is frustrating and show a regression.
>
> But I'm not satisfied with either of the 2 possible fixes mentioned above.
>
> Do you have any other thought ?
Hi Christian,
Thanks for the report/analysis and sorry for the inconvenience.
If I understand it correctly, I think pci_epf_test_bar_subrange_setup() should
simply roll back to the original BAR mapping when subrange setup fails.
In other words, if there are not enough free inbound regions for the subrange
test, the test should fail consistently and without leaving any side effect
behind. At the moment, it seems the failed setup leaves the BAR in a different
state (i.e. cleared), which then affects subsequent runs. That looks like a bug
in pci_epf_test_bar_subrange_setup().
If I understood the problem correctly, would something like the patch below
address it? My expectation is that the subrange mapping test would then fail
consistently on platforms that do not have enough free IB iATU regions.
[---8<---]
From 039548c87a5c7a038ac562272447c4620a4c1ad2 Mon Sep 17 00:00:00 2001
From: Koichiro Den <den@valinux.co.jp>
Date: Sat, 14 Mar 2026 12:58:04 +0900
Subject: [PATCH] PCI: endpoint: pci-epf-test: Roll back BAR mapping when
subrange setup fails
When the BAR subrange mapping test on DWC-based platforms fails due to
insufficient free inbound iATU regions,
pci_epf_test_bar_subrange_setup() returns an error (-ENOSPC) but does
not restore the original BAR mapping. This causes subsequent test runs
become confusing, since the failure leaves a room for the next subrange
mapping test to pass.
Fix this by restoring the original BAR mapping when preparation of the
subrange mapping fails.
Fixes: 6c5e6101423b ("PCI: endpoint: pci-epf-test: Add BAR subrange mapping test support")
Reported-by: Christian Bruel <christian.bruel@foss.st.com>
Signed-off-by: Koichiro Den <den@valinux.co.jp>
---
drivers/pci/endpoint/functions/pci-epf-test.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
index 582938b7b4f1..0e5958088b8f 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -891,12 +891,15 @@ static void pci_epf_test_bar_subrange_setup(struct pci_epf_test *epf_test,
ret = pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no, bar);
if (ret) {
dev_err(&epf->dev, "pci_epc_set_bar() failed: %d\n", ret);
bar->submap = old_submap;
bar->num_submap = old_nsub;
+ if (pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no, bar))
+ dev_warn(&epf->dev, "failed to roll back\n");
+
kfree(submap);
goto err;
}
kfree(old_submap);
/*
--
2.51.0
[---8<---]
I'd appreciate it if you could test this. Or, if I'm still missing the point of
your report, please let me know.
Best regards,
Koichiro
>
> thank you
>
> Christian
^ permalink raw reply related [flat|nested] 19+ messages in thread* Re: [PATCH v10 3/8] PCI: dwc: Advertise dynamic inbound mapping support
2026-03-14 4:33 ` Koichiro Den
@ 2026-03-16 12:41 ` Christian Bruel
2026-03-16 12:57 ` Niklas Cassel
0 siblings, 1 reply; 19+ messages in thread
From: Christian Bruel @ 2026-03-16 12:41 UTC (permalink / raw)
To: Koichiro Den
Cc: jingoohan1, mani, lpieralisi, kwilczynski, robh, bhelgaas, cassel,
Frank.Li, vigneshr, s-vadapalli, hongxing.zhu, l.stach, shawnguo,
s.hauer, kernel, festevam, minghuan.Lian, mingkai.hu, roy.zang,
jesper.nilsson, heiko, srikanth.thokala, marek.vasut+renesas,
yoshihiro.shimoda.uh, geert+renesas, magnus.damm, mcoquelin.stm32,
alexandre.torgue, thierry.reding, jonathanh, hayashi.kunihiko,
mhiramat, kishon, jirislaby, rongqianfeng, 18255117159, shawn.lin,
nicolas.frattaroli, linux.amoon, vidyas, shuah, linux-omap,
linux-pci, linux-arm-kernel, linux-kernel, imx, linuxppc-dev,
linux-arm-kernel, linux-rockchip, linux-arm-msm,
linux-renesas-soc, linux-stm32, linux-tegra, linux-kselftest
Hi Koichiro,
>
> If I understood the problem correctly, would something like the patch below
> address it? My expectation is that the subrange mapping test would then fail
> consistently on platforms that do not have enough free IB iATU regions.
>
Thank you for your patch. Yes, now the bar subrange tests fail
consistently, so that is enough to say this is not a regression.
However, I think there was a clear BAR missing somewhere before running
the tests in the EPF driver, as the BARs could be reallocated during the
other tests. This is not due to the subrange tests, but the EPF test
driver supposes a 1:1 BAR/ATU mapping. Now this assumption is broken.
I'm wondering if this could be improved to make the subrange tests pass
on all platforms
Cheers
Christian
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v10 3/8] PCI: dwc: Advertise dynamic inbound mapping support
2026-03-16 12:41 ` Christian Bruel
@ 2026-03-16 12:57 ` Niklas Cassel
2026-03-16 13:29 ` Christian Bruel
0 siblings, 1 reply; 19+ messages in thread
From: Niklas Cassel @ 2026-03-16 12:57 UTC (permalink / raw)
To: Christian Bruel
Cc: Koichiro Den, jingoohan1, mani, lpieralisi, kwilczynski, robh,
bhelgaas, Frank.Li, vigneshr, s-vadapalli, hongxing.zhu, l.stach,
shawnguo, s.hauer, kernel, festevam, minghuan.Lian, mingkai.hu,
roy.zang, jesper.nilsson, heiko, srikanth.thokala,
marek.vasut+renesas, yoshihiro.shimoda.uh, geert+renesas,
magnus.damm, mcoquelin.stm32, alexandre.torgue, thierry.reding,
jonathanh, hayashi.kunihiko, mhiramat, kishon, jirislaby,
rongqianfeng, 18255117159, shawn.lin, nicolas.frattaroli,
linux.amoon, vidyas, shuah, linux-omap, linux-pci,
linux-arm-kernel, linux-kernel, imx, linuxppc-dev,
linux-arm-kernel, linux-rockchip, linux-arm-msm,
linux-renesas-soc, linux-stm32, linux-tegra, linux-kselftest
On Mon, Mar 16, 2026 at 01:41:03PM +0100, Christian Bruel wrote:
> Hi Koichiro,
>
> >
> > If I understood the problem correctly, would something like the patch below
> > address it? My expectation is that the subrange mapping test would then fail
> > consistently on platforms that do not have enough free IB iATU regions.
> >
>
> Thank you for your patch. Yes, now the bar subrange tests fail consistently,
> so that is enough to say this is not a regression.
>
> However, I think there was a clear BAR missing somewhere before running the
> tests in the EPF driver, as the BARs could be reallocated during the other
> tests. This is not due to the subrange tests, but the EPF test driver
> supposes a 1:1 BAR/ATU mapping. Now this assumption is broken. I'm wondering
> if this could be improved to make the subrange tests pass on all platforms
Normally, you want one inbound iATU per enabled BAR, since you want the host
to be able to access all the enabled BARs at any time.
If you are thinking that we should somehow temporarily disable inbound
address translation for one of the enabled BARs, such that we can do "steal"
that iATU to test inbound subrange mapping, then I think that is a bad idea.
I think we should just let the test fail. Possibly we could call some API that
tells us that all inbound iATUs are occupied, and then SKIP instead of FAIL
the inbound subrange test case.
If you really want to test/use inbound subrange mapping, even if your SoC has
a very limited number of inbound iATUs, then I think a better solution is to
mark one or multiple of your BARs as disabled:
https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/commit/?h=endpoint&id=33642e9e36dc084e4fc9245a266c9843bc8303b9
Then you should have at least one more inbound iATU available, and should be
able to run the inbound subrange test case.
Kind regards,
Niklas
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v10 3/8] PCI: dwc: Advertise dynamic inbound mapping support
2026-03-16 12:57 ` Niklas Cassel
@ 2026-03-16 13:29 ` Christian Bruel
2026-03-16 13:50 ` Koichiro Den
0 siblings, 1 reply; 19+ messages in thread
From: Christian Bruel @ 2026-03-16 13:29 UTC (permalink / raw)
To: Niklas Cassel
Cc: Koichiro Den, jingoohan1, mani, lpieralisi, kwilczynski, robh,
bhelgaas, Frank.Li, vigneshr, s-vadapalli, hongxing.zhu, l.stach,
shawnguo, s.hauer, kernel, festevam, minghuan.Lian, mingkai.hu,
roy.zang, jesper.nilsson, heiko, srikanth.thokala,
marek.vasut+renesas, yoshihiro.shimoda.uh, geert+renesas,
magnus.damm, mcoquelin.stm32, alexandre.torgue, thierry.reding,
jonathanh, hayashi.kunihiko, mhiramat, kishon, jirislaby,
rongqianfeng, 18255117159, shawn.lin, nicolas.frattaroli,
linux.amoon, vidyas, shuah, linux-omap, linux-pci,
linux-arm-kernel, linux-kernel, imx, linuxppc-dev,
linux-arm-kernel, linux-rockchip, linux-arm-msm,
linux-renesas-soc, linux-stm32, linux-tegra, linux-kselftest
On 3/16/26 13:57, Niklas Cassel wrote:
> On Mon, Mar 16, 2026 at 01:41:03PM +0100, Christian Bruel wrote:
>> Hi Koichiro,
>>
>>>
>>> If I understood the problem correctly, would something like the patch below
>>> address it? My expectation is that the subrange mapping test would then fail
>>> consistently on platforms that do not have enough free IB iATU regions.
>>>
>>
>> Thank you for your patch. Yes, now the bar subrange tests fail consistently,
>> so that is enough to say this is not a regression.
>>
>> However, I think there was a clear BAR missing somewhere before running the
>> tests in the EPF driver, as the BARs could be reallocated during the other
>> tests. This is not due to the subrange tests, but the EPF test driver
>> supposes a 1:1 BAR/ATU mapping. Now this assumption is broken. I'm wondering
>> if this could be improved to make the subrange tests pass on all platforms
>
> Normally, you want one inbound iATU per enabled BAR, since you want the host
> to be able to access all the enabled BARs at any time.
>
> If you are thinking that we should somehow temporarily disable inbound
> address translation for one of the enabled BARs, such that we can do "steal"
> that iATU to test inbound subrange mapping, then I think that is a bad idea.
yes, I was thinking something about restricting the iATU entry lifetime
during the BAR test duration and restoring after. But OK I agree, not good.
>
> I think we should just let the test fail. Possibly we could call some API that
> tells us that all inbound iATUs are occupied, and then SKIP instead of FAIL
> the inbound subrange test case.
>
> If you really want to test/use inbound subrange mapping, even if your SoC has
> a very limited number of inbound iATUs, then I think a better solution is to
> mark one or multiple of your BARs as disabled:
> https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/commit/?h=endpoint&id=33642e9e36dc084e4fc9245a266c9843bc8303b9
>
> Then you should have at least one more inbound iATU available, and should be
> able to run the inbound subrange test case.
Yes cherry-picking the BAR_DISABLED support, I can now test the subrange
with Koichiro's fixup.
./pci_endpoint_test -t BAR_SUBRANGE_TEST
TAP version 13
1..6
# Starting 6 tests from 6 test cases.
# RUN pci_ep_bar.BAR0.BAR_SUBRANGE_TEST ...
# SKIP BAR is test register space
# OK pci_ep_bar.BAR0.BAR_SUBRANGE_TEST
ok 1 pci_ep_bar.BAR0.BAR_SUBRANGE_TEST # SKIP BAR is test register space
# RUN pci_ep_bar.BAR1.BAR_SUBRANGE_TEST ...
# OK pci_ep_bar.BAR1.BAR_SUBRANGE_TEST
ok 2 pci_ep_bar.BAR1.BAR_SUBRANGE_TEST
# RUN pci_ep_bar.BAR2.BAR_SUBRANGE_TEST ...
# OK pci_ep_bar.BAR2.BAR_SUBRANGE_TEST
ok 3 pci_ep_bar.BAR2.BAR_SUBRANGE_TEST
# RUN pci_ep_bar.BAR3.BAR_SUBRANGE_TEST ...
# SKIP BAR is disabled
# OK pci_ep_bar.BAR3.BAR_SUBRANGE_TEST
ok 4 pci_ep_bar.BAR3.BAR_SUBRANGE_TEST # SKIP BAR is disabled
# RUN pci_ep_bar.BAR4.BAR_SUBRANGE_TEST ...
# SKIP BAR is disabled
# OK pci_ep_bar.BAR4.BAR_SUBRANGE_TEST
ok 5 pci_ep_bar.BAR4.BAR_SUBRANGE_TEST # SKIP BAR is disabled
# RUN pci_ep_bar.BAR5.BAR_SUBRANGE_TEST ...
# SKIP BAR is disabled
# OK pci_ep_bar.BAR5.BAR_SUBRANGE_TEST
ok 6 pci_ep_bar.BAR5.BAR_SUBRANGE_TEST # SKIP BAR is disabled
# PASSED: 6 / 6 tests passed.
# 4 skipped test(s) detected. Consider enabling relevant config options
to improve coverage.
# Totals: pass:2 fail:0 xfail:0 xpass:0 skip:4 error:0
Thank you,
Christian
>
>
> Kind regards,
> Niklas
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v10 3/8] PCI: dwc: Advertise dynamic inbound mapping support
2026-03-16 13:29 ` Christian Bruel
@ 2026-03-16 13:50 ` Koichiro Den
0 siblings, 0 replies; 19+ messages in thread
From: Koichiro Den @ 2026-03-16 13:50 UTC (permalink / raw)
To: Christian Bruel, Niklas Cassel, Bjorn Helgaas
Cc: jingoohan1, mani, lpieralisi, kwilczynski, robh, Frank.Li,
vigneshr, s-vadapalli, hongxing.zhu, l.stach, shawnguo, s.hauer,
kernel, festevam, minghuan.Lian, mingkai.hu, roy.zang,
jesper.nilsson, heiko, srikanth.thokala, marek.vasut+renesas,
yoshihiro.shimoda.uh, geert+renesas, magnus.damm, mcoquelin.stm32,
alexandre.torgue, thierry.reding, jonathanh, hayashi.kunihiko,
mhiramat, kishon, jirislaby, rongqianfeng, 18255117159, shawn.lin,
nicolas.frattaroli, linux.amoon, vidyas, shuah, linux-omap,
linux-pci, linux-arm-kernel, linux-kernel, imx, linuxppc-dev,
linux-arm-kernel, linux-rockchip, linux-arm-msm,
linux-renesas-soc, linux-stm32, linux-tegra, linux-kselftest
On Mon, Mar 16, 2026 at 02:29:54PM +0100, Christian Bruel wrote:
>
>
> On 3/16/26 13:57, Niklas Cassel wrote:
> > On Mon, Mar 16, 2026 at 01:41:03PM +0100, Christian Bruel wrote:
> > > Hi Koichiro,
> > >
> > > >
> > > > If I understood the problem correctly, would something like the patch below
> > > > address it? My expectation is that the subrange mapping test would then fail
> > > > consistently on platforms that do not have enough free IB iATU regions.
> > > >
> > >
> > > Thank you for your patch. Yes, now the bar subrange tests fail consistently,
> > > so that is enough to say this is not a regression.
> > >
> > > However, I think there was a clear BAR missing somewhere before running the
> > > tests in the EPF driver, as the BARs could be reallocated during the other
> > > tests. This is not due to the subrange tests, but the EPF test driver
> > > supposes a 1:1 BAR/ATU mapping. Now this assumption is broken. I'm wondering
> > > if this could be improved to make the subrange tests pass on all platforms
> >
> > Normally, you want one inbound iATU per enabled BAR, since you want the host
> > to be able to access all the enabled BARs at any time.
> >
> > If you are thinking that we should somehow temporarily disable inbound
> > address translation for one of the enabled BARs, such that we can do "steal"
> > that iATU to test inbound subrange mapping, then I think that is a bad idea.
>
> yes, I was thinking something about restricting the iATU entry lifetime
> during the BAR test duration and restoring after. But OK I agree, not good.
>
> >
> > I think we should just let the test fail. Possibly we could call some API that
> > tells us that all inbound iATUs are occupied, and then SKIP instead of FAIL
> > the inbound subrange test case.
> >
> > If you really want to test/use inbound subrange mapping, even if your SoC has
> > a very limited number of inbound iATUs, then I think a better solution is to
> > mark one or multiple of your BARs as disabled:
> > https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/commit/?h=endpoint&id=33642e9e36dc084e4fc9245a266c9843bc8303b9
> >
> > Then you should have at least one more inbound iATU available, and should be
> > able to run the inbound subrange test case.
>
> Yes cherry-picking the BAR_DISABLED support, I can now test the subrange
> with Koichiro's fixup.
>
> ./pci_endpoint_test -t BAR_SUBRANGE_TEST
> TAP version 13
> 1..6
> # Starting 6 tests from 6 test cases.
> # RUN pci_ep_bar.BAR0.BAR_SUBRANGE_TEST ...
> # SKIP BAR is test register space
> # OK pci_ep_bar.BAR0.BAR_SUBRANGE_TEST
> ok 1 pci_ep_bar.BAR0.BAR_SUBRANGE_TEST # SKIP BAR is test register space
> # RUN pci_ep_bar.BAR1.BAR_SUBRANGE_TEST ...
> # OK pci_ep_bar.BAR1.BAR_SUBRANGE_TEST
> ok 2 pci_ep_bar.BAR1.BAR_SUBRANGE_TEST
> # RUN pci_ep_bar.BAR2.BAR_SUBRANGE_TEST ...
> # OK pci_ep_bar.BAR2.BAR_SUBRANGE_TEST
> ok 3 pci_ep_bar.BAR2.BAR_SUBRANGE_TEST
> # RUN pci_ep_bar.BAR3.BAR_SUBRANGE_TEST ...
> # SKIP BAR is disabled
> # OK pci_ep_bar.BAR3.BAR_SUBRANGE_TEST
> ok 4 pci_ep_bar.BAR3.BAR_SUBRANGE_TEST # SKIP BAR is disabled
> # RUN pci_ep_bar.BAR4.BAR_SUBRANGE_TEST ...
> # SKIP BAR is disabled
> # OK pci_ep_bar.BAR4.BAR_SUBRANGE_TEST
> ok 5 pci_ep_bar.BAR4.BAR_SUBRANGE_TEST # SKIP BAR is disabled
> # RUN pci_ep_bar.BAR5.BAR_SUBRANGE_TEST ...
> # SKIP BAR is disabled
> # OK pci_ep_bar.BAR5.BAR_SUBRANGE_TEST
> ok 6 pci_ep_bar.BAR5.BAR_SUBRANGE_TEST # SKIP BAR is disabled
> # PASSED: 6 / 6 tests passed.
> # 4 skipped test(s) detected. Consider enabling relevant config options to
> improve coverage.
> # Totals: pass:2 fail:0 xfail:0 xpass:0 skip:4 error:0
>
> Thank you,
Christian, thank you for testing.
Niklas, thank you for the follow-up. I agree with your assessment.
Bjorn, I'll submit the tested-patch shortly. Sorry for the trouble.
Best regards,
Koichiro
>
> Christian
> >
> >
> > Kind regards,
> > Niklas
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH v10 4/8] PCI: dwc: ep: Support BAR subrange inbound mapping via Address Match Mode iATU
2026-01-24 14:50 [PATCH v10 0/8] PCI: endpoint: BAR subrange mapping support Koichiro Den
` (2 preceding siblings ...)
2026-01-24 14:50 ` [PATCH v10 3/8] PCI: dwc: Advertise dynamic inbound " Koichiro Den
@ 2026-01-24 14:50 ` Koichiro Den
2026-01-26 10:25 ` Niklas Cassel
2026-01-24 14:50 ` [PATCH v10 5/8] Documentation: PCI: endpoint: Clarify pci_epc_set_bar() usage Koichiro Den
` (4 subsequent siblings)
8 siblings, 1 reply; 19+ messages in thread
From: Koichiro Den @ 2026-01-24 14:50 UTC (permalink / raw)
To: jingoohan1, mani, lpieralisi, kwilczynski, robh, bhelgaas, cassel,
Frank.Li
Cc: vigneshr, s-vadapalli, hongxing.zhu, l.stach, shawnguo, s.hauer,
kernel, festevam, minghuan.Lian, mingkai.hu, roy.zang,
jesper.nilsson, heiko, srikanth.thokala, marek.vasut+renesas,
yoshihiro.shimoda.uh, geert+renesas, magnus.damm, christian.bruel,
mcoquelin.stm32, alexandre.torgue, thierry.reding, jonathanh,
hayashi.kunihiko, mhiramat, kishon, jirislaby, rongqianfeng,
18255117159, shawn.lin, nicolas.frattaroli, linux.amoon, vidyas,
shuah, linux-omap, linux-pci, linux-arm-kernel, linux-kernel, imx,
linuxppc-dev, linux-arm-kernel, linux-rockchip, linux-arm-msm,
linux-renesas-soc, linux-stm32, linux-tegra, linux-kselftest
Extend dw_pcie_ep_set_bar() to support inbound mappings for BAR
subranges using Address Match Mode IB iATU when pci_epf_bar.num_submap
is non-zero.
Rename the existing BAR-match helper into dw_pcie_ep_ib_atu_bar() and
introduce dw_pcie_ep_ib_atu_addr() for Address Match Mode. When
num_submap is non-zero, read the assigned BAR base address and program
one inbound iATU window per subrange. Validate the submap array before
programming:
- each subrange is aligned to pci->region_align
- subranges cover the whole BAR (no gaps and no overlaps)
Track Address Match Mode mappings and tear them down on clear_bar() and
on set_bar() error paths to avoid leaving half-programmed state or
untranslated BAR holes.
Advertise this capability by extending the common feature bit
initializer macro (DWC_EPC_COMMON_FEATURES).
This enables multiple inbound windows within a single BAR, which is
useful on platforms where usable BARs are scarce but EPFs need multiple
inbound regions.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Koichiro Den <den@valinux.co.jp>
---
.../pci/controller/dwc/pcie-designware-ep.c | 212 +++++++++++++++++-
drivers/pci/controller/dwc/pcie-designware.h | 7 +-
2 files changed, 208 insertions(+), 11 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
index cfd59899c7b8..de09cd786edc 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -100,9 +100,10 @@ static int dw_pcie_ep_write_header(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
return 0;
}
-static int dw_pcie_ep_inbound_atu(struct dw_pcie_ep *ep, u8 func_no, int type,
- dma_addr_t parent_bus_addr, enum pci_barno bar,
- size_t size)
+/* BAR Match Mode inbound iATU mapping */
+static int dw_pcie_ep_ib_atu_bar(struct dw_pcie_ep *ep, u8 func_no, int type,
+ dma_addr_t parent_bus_addr, enum pci_barno bar,
+ size_t size)
{
int ret;
u32 free_win;
@@ -135,6 +136,179 @@ static int dw_pcie_ep_inbound_atu(struct dw_pcie_ep *ep, u8 func_no, int type,
return 0;
}
+static void dw_pcie_ep_clear_ib_maps(struct dw_pcie_ep *ep, enum pci_barno bar)
+{
+ struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+ struct device *dev = pci->dev;
+ unsigned int i, num;
+ u32 atu_index;
+ u32 *indexes;
+
+ /* Tear down the BAR Match Mode mapping, if any. */
+ if (ep->bar_to_atu[bar]) {
+ atu_index = ep->bar_to_atu[bar] - 1;
+ dw_pcie_disable_atu(pci, PCIE_ATU_REGION_DIR_IB, atu_index);
+ clear_bit(atu_index, ep->ib_window_map);
+ ep->bar_to_atu[bar] = 0;
+ }
+
+ /* Tear down all Address Match Mode mappings, if any. */
+ indexes = ep->ib_atu_indexes[bar];
+ num = ep->num_ib_atu_indexes[bar];
+ ep->ib_atu_indexes[bar] = NULL;
+ ep->num_ib_atu_indexes[bar] = 0;
+ if (!indexes)
+ return;
+ for (i = 0; i < num; i++) {
+ dw_pcie_disable_atu(pci, PCIE_ATU_REGION_DIR_IB, indexes[i]);
+ clear_bit(indexes[i], ep->ib_window_map);
+ }
+ devm_kfree(dev, indexes);
+}
+
+static u64 dw_pcie_ep_read_bar_assigned(struct dw_pcie_ep *ep, u8 func_no,
+ enum pci_barno bar, int flags)
+{
+ u32 reg = PCI_BASE_ADDRESS_0 + (4 * bar);
+ u32 lo, hi;
+ u64 addr;
+
+ lo = dw_pcie_ep_readl_dbi(ep, func_no, reg);
+
+ if (flags & PCI_BASE_ADDRESS_SPACE)
+ return lo & PCI_BASE_ADDRESS_IO_MASK;
+
+ addr = lo & PCI_BASE_ADDRESS_MEM_MASK;
+ if (!(flags & PCI_BASE_ADDRESS_MEM_TYPE_64))
+ return addr;
+
+ hi = dw_pcie_ep_readl_dbi(ep, func_no, reg + 4);
+ return addr | ((u64)hi << 32);
+}
+
+static int dw_pcie_ep_validate_submap(struct dw_pcie_ep *ep,
+ const struct pci_epf_bar_submap *submap,
+ unsigned int num_submap, size_t bar_size)
+{
+ struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+ u32 align = pci->region_align;
+ size_t off = 0;
+ unsigned int i;
+ size_t size;
+
+ if (!align || !IS_ALIGNED(bar_size, align))
+ return -EINVAL;
+
+ /*
+ * The submap array order defines the BAR layout (submap[0] starts
+ * at offset 0 and each entry immediately follows the previous
+ * one). Here, validate that it forms a strict, gapless
+ * decomposition of the BAR:
+ * - each entry has a non-zero size
+ * - sizes, implicit offsets and phys_addr are aligned to
+ * pci->region_align
+ * - each entry lies within the BAR range
+ * - the entries exactly cover the whole BAR
+ *
+ * Note: dw_pcie_prog_inbound_atu() also checks alignment for the
+ * PCI address and the target phys_addr, but validating up-front
+ * avoids partially programming iATU windows in vain.
+ */
+ for (i = 0; i < num_submap; i++) {
+ size = submap[i].size;
+
+ if (!size)
+ return -EINVAL;
+
+ if (!IS_ALIGNED(size, align) || !IS_ALIGNED(off, align))
+ return -EINVAL;
+
+ if (!IS_ALIGNED(submap[i].phys_addr, align))
+ return -EINVAL;
+
+ if (off > bar_size || size > bar_size - off)
+ return -EINVAL;
+
+ off += size;
+ }
+ if (off != bar_size)
+ return -EINVAL;
+
+ return 0;
+}
+
+/* Address Match Mode inbound iATU mapping */
+static int dw_pcie_ep_ib_atu_addr(struct dw_pcie_ep *ep, u8 func_no, int type,
+ const struct pci_epf_bar *epf_bar)
+{
+ const struct pci_epf_bar_submap *submap = epf_bar->submap;
+ struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+ enum pci_barno bar = epf_bar->barno;
+ struct device *dev = pci->dev;
+ u64 pci_addr, parent_bus_addr;
+ u64 size, base, off = 0;
+ int free_win, ret;
+ unsigned int i;
+ u32 *indexes;
+
+ if (!epf_bar->num_submap || !submap || !epf_bar->size)
+ return -EINVAL;
+
+ ret = dw_pcie_ep_validate_submap(ep, submap, epf_bar->num_submap,
+ epf_bar->size);
+ if (ret)
+ return ret;
+
+ base = dw_pcie_ep_read_bar_assigned(ep, func_no, bar, epf_bar->flags);
+ if (!base) {
+ dev_err(dev,
+ "BAR%u not assigned, cannot set up sub-range mappings\n",
+ bar);
+ return -EINVAL;
+ }
+
+ indexes = devm_kcalloc(dev, epf_bar->num_submap, sizeof(*indexes),
+ GFP_KERNEL);
+ if (!indexes)
+ return -ENOMEM;
+
+ ep->ib_atu_indexes[bar] = indexes;
+ ep->num_ib_atu_indexes[bar] = 0;
+
+ for (i = 0; i < epf_bar->num_submap; i++) {
+ size = submap[i].size;
+ parent_bus_addr = submap[i].phys_addr;
+
+ if (off > (~0ULL) - base) {
+ ret = -EINVAL;
+ goto err;
+ }
+
+ pci_addr = base + off;
+ off += size;
+
+ free_win = find_first_zero_bit(ep->ib_window_map,
+ pci->num_ib_windows);
+ if (free_win >= pci->num_ib_windows) {
+ ret = -ENOSPC;
+ goto err;
+ }
+
+ ret = dw_pcie_prog_inbound_atu(pci, free_win, type,
+ parent_bus_addr, pci_addr, size);
+ if (ret)
+ goto err;
+
+ set_bit(free_win, ep->ib_window_map);
+ indexes[i] = free_win;
+ ep->num_ib_atu_indexes[bar] = i + 1;
+ }
+ return 0;
+err:
+ dw_pcie_ep_clear_ib_maps(ep, bar);
+ return ret;
+}
+
static int dw_pcie_ep_outbound_atu(struct dw_pcie_ep *ep,
struct dw_pcie_ob_atu_cfg *atu)
{
@@ -165,17 +339,15 @@ static void dw_pcie_ep_clear_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
struct dw_pcie_ep *ep = epc_get_drvdata(epc);
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
enum pci_barno bar = epf_bar->barno;
- u32 atu_index = ep->bar_to_atu[bar] - 1;
- if (!ep->bar_to_atu[bar])
+ if (!ep->epf_bar[bar])
return;
__dw_pcie_ep_reset_bar(pci, func_no, bar, epf_bar->flags);
- dw_pcie_disable_atu(pci, PCIE_ATU_REGION_DIR_IB, atu_index);
- clear_bit(atu_index, ep->ib_window_map);
+ dw_pcie_ep_clear_ib_maps(ep, bar);
+
ep->epf_bar[bar] = NULL;
- ep->bar_to_atu[bar] = 0;
}
static unsigned int dw_pcie_ep_get_rebar_offset(struct dw_pcie *pci,
@@ -331,11 +503,27 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
ep->epf_bar[bar]->flags != flags)
return -EINVAL;
+ /*
+ * When dynamically changing a BAR, tear down any existing
+ * mappings before re-programming.
+ */
+ if (ep->epf_bar[bar]->num_submap || epf_bar->num_submap)
+ dw_pcie_ep_clear_ib_maps(ep, bar);
+
/*
* When dynamically changing a BAR, skip writing the BAR reg, as
* that would clear the BAR's PCI address assigned by the host.
*/
goto config_atu;
+ } else {
+ /*
+ * Subrange mapping is an update-only operation.
+ * The BAR must have been configured once without submaps so that
+ * subsequent set_bar() calls can update inbound mappings without
+ * touching the BAR register (and clobbering the host-assigned address).
+ */
+ if (epf_bar->num_submap)
+ return -EINVAL;
}
bar_type = dw_pcie_ep_get_bar_type(ep, bar);
@@ -369,8 +557,12 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
else
type = PCIE_ATU_TYPE_IO;
- ret = dw_pcie_ep_inbound_atu(ep, func_no, type, epf_bar->phys_addr, bar,
- size);
+ if (epf_bar->num_submap)
+ ret = dw_pcie_ep_ib_atu_addr(ep, func_no, type, epf_bar);
+ else
+ ret = dw_pcie_ep_ib_atu_bar(ep, func_no, type,
+ epf_bar->phys_addr, bar, size);
+
if (ret)
return ret;
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index 7ca9d0f6b7f2..8f170122ad78 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -306,7 +306,8 @@
#define DMA_LLP_MEM_SIZE PAGE_SIZE
/* Common struct pci_epc_feature bits among DWC EP glue drivers */
-#define DWC_EPC_COMMON_FEATURES .dynamic_inbound_mapping = true
+#define DWC_EPC_COMMON_FEATURES .dynamic_inbound_mapping = true, \
+ .subrange_mapping = true
struct dw_pcie;
struct dw_pcie_rp;
@@ -487,6 +488,10 @@ struct dw_pcie_ep {
phys_addr_t msi_mem_phys;
struct pci_epf_bar *epf_bar[PCI_STD_NUM_BARS];
+ /* Only for Address Match Mode inbound iATU */
+ u32 *ib_atu_indexes[PCI_STD_NUM_BARS];
+ unsigned int num_ib_atu_indexes[PCI_STD_NUM_BARS];
+
/* MSI outbound iATU state */
bool msi_iatu_mapped;
u64 msi_msg_addr;
--
2.51.0
^ permalink raw reply related [flat|nested] 19+ messages in thread* Re: [PATCH v10 4/8] PCI: dwc: ep: Support BAR subrange inbound mapping via Address Match Mode iATU
2026-01-24 14:50 ` [PATCH v10 4/8] PCI: dwc: ep: Support BAR subrange inbound mapping via Address Match Mode iATU Koichiro Den
@ 2026-01-26 10:25 ` Niklas Cassel
0 siblings, 0 replies; 19+ messages in thread
From: Niklas Cassel @ 2026-01-26 10:25 UTC (permalink / raw)
To: Koichiro Den
Cc: jingoohan1, mani, lpieralisi, kwilczynski, robh, bhelgaas,
Frank.Li, vigneshr, s-vadapalli, hongxing.zhu, l.stach, shawnguo,
s.hauer, kernel, festevam, minghuan.Lian, mingkai.hu, roy.zang,
jesper.nilsson, heiko, srikanth.thokala, marek.vasut+renesas,
yoshihiro.shimoda.uh, geert+renesas, magnus.damm, christian.bruel,
mcoquelin.stm32, alexandre.torgue, thierry.reding, jonathanh,
hayashi.kunihiko, mhiramat, kishon, jirislaby, rongqianfeng,
18255117159, shawn.lin, nicolas.frattaroli, linux.amoon, vidyas,
shuah, linux-omap, linux-pci, linux-arm-kernel, linux-kernel, imx,
linuxppc-dev, linux-arm-kernel, linux-rockchip, linux-arm-msm,
linux-renesas-soc, linux-stm32, linux-tegra, linux-kselftest
On Sat, Jan 24, 2026 at 11:50:08PM +0900, Koichiro Den wrote:
> Extend dw_pcie_ep_set_bar() to support inbound mappings for BAR
> subranges using Address Match Mode IB iATU when pci_epf_bar.num_submap
> is non-zero.
>
> Rename the existing BAR-match helper into dw_pcie_ep_ib_atu_bar() and
> introduce dw_pcie_ep_ib_atu_addr() for Address Match Mode. When
> num_submap is non-zero, read the assigned BAR base address and program
> one inbound iATU window per subrange. Validate the submap array before
> programming:
> - each subrange is aligned to pci->region_align
> - subranges cover the whole BAR (no gaps and no overlaps)
>
> Track Address Match Mode mappings and tear them down on clear_bar() and
> on set_bar() error paths to avoid leaving half-programmed state or
> untranslated BAR holes.
>
> Advertise this capability by extending the common feature bit
> initializer macro (DWC_EPC_COMMON_FEATURES).
>
> This enables multiple inbound windows within a single BAR, which is
> useful on platforms where usable BARs are scarce but EPFs need multiple
> inbound regions.
>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Signed-off-by: Koichiro Den <den@valinux.co.jp>
> ---
Reviewed-by: Niklas Cassel <cassel@kernel.org>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH v10 5/8] Documentation: PCI: endpoint: Clarify pci_epc_set_bar() usage
2026-01-24 14:50 [PATCH v10 0/8] PCI: endpoint: BAR subrange mapping support Koichiro Den
` (3 preceding siblings ...)
2026-01-24 14:50 ` [PATCH v10 4/8] PCI: dwc: ep: Support BAR subrange inbound mapping via Address Match Mode iATU Koichiro Den
@ 2026-01-24 14:50 ` Koichiro Den
2026-01-24 14:50 ` [PATCH v10 6/8] PCI: endpoint: pci-epf-test: Add BAR subrange mapping test support Koichiro Den
` (3 subsequent siblings)
8 siblings, 0 replies; 19+ messages in thread
From: Koichiro Den @ 2026-01-24 14:50 UTC (permalink / raw)
To: jingoohan1, mani, lpieralisi, kwilczynski, robh, bhelgaas, cassel,
Frank.Li
Cc: vigneshr, s-vadapalli, hongxing.zhu, l.stach, shawnguo, s.hauer,
kernel, festevam, minghuan.Lian, mingkai.hu, roy.zang,
jesper.nilsson, heiko, srikanth.thokala, marek.vasut+renesas,
yoshihiro.shimoda.uh, geert+renesas, magnus.damm, christian.bruel,
mcoquelin.stm32, alexandre.torgue, thierry.reding, jonathanh,
hayashi.kunihiko, mhiramat, kishon, jirislaby, rongqianfeng,
18255117159, shawn.lin, nicolas.frattaroli, linux.amoon, vidyas,
shuah, linux-omap, linux-pci, linux-arm-kernel, linux-kernel, imx,
linuxppc-dev, linux-arm-kernel, linux-rockchip, linux-arm-msm,
linux-renesas-soc, linux-stm32, linux-tegra, linux-kselftest
The current documentation implies that pci_epc_set_bar() is only used
before the host enumerates the endpoint.
In practice, some Endpoint Controllers support calling pci_epc_set_bar()
multiple times for the same BAR (without clearing it) in order to update
inbound address translations after the host has programmed the BAR base
address, which some Endpoint Functions such as vNTB already rely on.
Add document text for that.
Also document the expected call flow for BAR subrange mapping
(pci_epf_bar.num_submap / pci_epf_bar.submap), which may require a
second pci_epc_set_bar() call after the host has programmed the BAR base
address.
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Koichiro Den <den@valinux.co.jp>
---
Documentation/PCI/endpoint/pci-endpoint.rst | 24 +++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/Documentation/PCI/endpoint/pci-endpoint.rst b/Documentation/PCI/endpoint/pci-endpoint.rst
index 0741c8cbd74e..4697377adeae 100644
--- a/Documentation/PCI/endpoint/pci-endpoint.rst
+++ b/Documentation/PCI/endpoint/pci-endpoint.rst
@@ -95,6 +95,30 @@ by the PCI endpoint function driver.
Register space of the function driver is usually configured
using this API.
+ Some endpoint controllers also support calling pci_epc_set_bar() again
+ for the same BAR (without calling pci_epc_clear_bar()) to update inbound
+ address translations after the host has programmed the BAR base address.
+ Endpoint function drivers can check this capability via the
+ dynamic_inbound_mapping EPC feature bit.
+
+ When pci_epf_bar.num_submap is non-zero, the endpoint function driver is
+ requesting BAR subrange mapping using pci_epf_bar.submap. This requires
+ the EPC to advertise support via the subrange_mapping EPC feature bit.
+
+ When an EPF driver wants to make use of the inbound subrange mapping
+ feature, it requires that the BAR base address has been programmed by
+ the host during enumeration. Thus, it needs to call pci_epc_set_bar()
+ twice for the same BAR (requires dynamic_inbound_mapping): first with
+ num_submap set to zero and configuring the BAR size, then after the PCIe
+ link is up and the host enumerates the endpoint and programs the BAR
+ base address, again with num_submap set to non-zero value.
+
+ Note that when making use of the inbound subrange mapping feature, the
+ EPF driver must not call pci_epc_clear_bar() between the two
+ pci_epc_set_bar() calls, because clearing the BAR can clear/disable the
+ BAR register or BAR decode on the endpoint while the host still expects
+ the assigned BAR address to remain valid.
+
* pci_epc_clear_bar()
The PCI endpoint function driver should use pci_epc_clear_bar() to reset
--
2.51.0
^ permalink raw reply related [flat|nested] 19+ messages in thread* [PATCH v10 6/8] PCI: endpoint: pci-epf-test: Add BAR subrange mapping test support
2026-01-24 14:50 [PATCH v10 0/8] PCI: endpoint: BAR subrange mapping support Koichiro Den
` (4 preceding siblings ...)
2026-01-24 14:50 ` [PATCH v10 5/8] Documentation: PCI: endpoint: Clarify pci_epc_set_bar() usage Koichiro Den
@ 2026-01-24 14:50 ` Koichiro Den
2026-01-24 14:50 ` [PATCH v10 7/8] misc: pci_endpoint_test: Add BAR subrange mapping test case Koichiro Den
` (2 subsequent siblings)
8 siblings, 0 replies; 19+ messages in thread
From: Koichiro Den @ 2026-01-24 14:50 UTC (permalink / raw)
To: jingoohan1, mani, lpieralisi, kwilczynski, robh, bhelgaas, cassel,
Frank.Li
Cc: vigneshr, s-vadapalli, hongxing.zhu, l.stach, shawnguo, s.hauer,
kernel, festevam, minghuan.Lian, mingkai.hu, roy.zang,
jesper.nilsson, heiko, srikanth.thokala, marek.vasut+renesas,
yoshihiro.shimoda.uh, geert+renesas, magnus.damm, christian.bruel,
mcoquelin.stm32, alexandre.torgue, thierry.reding, jonathanh,
hayashi.kunihiko, mhiramat, kishon, jirislaby, rongqianfeng,
18255117159, shawn.lin, nicolas.frattaroli, linux.amoon, vidyas,
shuah, linux-omap, linux-pci, linux-arm-kernel, linux-kernel, imx,
linuxppc-dev, linux-arm-kernel, linux-rockchip, linux-arm-msm,
linux-renesas-soc, linux-stm32, linux-tegra, linux-kselftest
Extend pci-epf-test so that pci_endpoint_test can exercise BAR subrange
mapping end-to-end.
Add BAR_SUBRANGE_SETUP/CLEAR commands that program (and tear down) a
simple 2-subrange layout for a selected BAR. The endpoint deliberately
permutes the physical backing regions (swap the halves) and writes a
deterministic signature byte per subrange. This allows the RC to verify
that the submap order is actually applied, not just that reads/writes
work with an identity mapping.
Advertise CAP_SUBRANGE_MAPPING only when the underlying EPC supports
dynamic_inbound_mapping and subrange_mapping. Also bump the default BAR
sizes (BAR0-4) to 128 KiB so that split subranges are large enough to
satisfy common inbound-translation alignment constraints. E.g. for DWC
EP, the default and maximum CX_ATU_MIN_REGION_SIZE is 64 kB, so 128 KiB
is sufficient for DWC-based EP platforms for 2-subrange testing.
Signed-off-by: Koichiro Den <den@valinux.co.jp>
---
drivers/pci/endpoint/functions/pci-epf-test.c | 172 +++++++++++++++++-
1 file changed, 171 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
index debd235253c5..1cc630a2ee75 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -33,6 +33,8 @@
#define COMMAND_COPY BIT(5)
#define COMMAND_ENABLE_DOORBELL BIT(6)
#define COMMAND_DISABLE_DOORBELL BIT(7)
+#define COMMAND_BAR_SUBRANGE_SETUP BIT(8)
+#define COMMAND_BAR_SUBRANGE_CLEAR BIT(9)
#define STATUS_READ_SUCCESS BIT(0)
#define STATUS_READ_FAIL BIT(1)
@@ -48,6 +50,10 @@
#define STATUS_DOORBELL_ENABLE_FAIL BIT(11)
#define STATUS_DOORBELL_DISABLE_SUCCESS BIT(12)
#define STATUS_DOORBELL_DISABLE_FAIL BIT(13)
+#define STATUS_BAR_SUBRANGE_SETUP_SUCCESS BIT(14)
+#define STATUS_BAR_SUBRANGE_SETUP_FAIL BIT(15)
+#define STATUS_BAR_SUBRANGE_CLEAR_SUCCESS BIT(16)
+#define STATUS_BAR_SUBRANGE_CLEAR_FAIL BIT(17)
#define FLAG_USE_DMA BIT(0)
@@ -57,6 +63,9 @@
#define CAP_MSI BIT(1)
#define CAP_MSIX BIT(2)
#define CAP_INTX BIT(3)
+#define CAP_SUBRANGE_MAPPING BIT(4)
+
+#define PCI_EPF_TEST_BAR_SUBRANGE_NSUB 2
static struct workqueue_struct *kpcitest_workqueue;
@@ -102,7 +111,7 @@ static struct pci_epf_header test_header = {
.interrupt_pin = PCI_INTERRUPT_INTA,
};
-static size_t bar_size[] = { 512, 512, 1024, 16384, 131072, 1048576 };
+static size_t bar_size[] = { 131072, 131072, 131072, 131072, 131072, 1048576 };
static void pci_epf_test_dma_callback(void *param)
{
@@ -806,6 +815,155 @@ static void pci_epf_test_disable_doorbell(struct pci_epf_test *epf_test,
reg->status = cpu_to_le32(status);
}
+static u8 pci_epf_test_subrange_sig_byte(enum pci_barno barno,
+ unsigned int subno)
+{
+ return 0x50 + (barno * 8) + subno;
+}
+
+static void pci_epf_test_bar_subrange_setup(struct pci_epf_test *epf_test,
+ struct pci_epf_test_reg *reg)
+{
+ struct pci_epf_bar_submap *submap, *old_submap;
+ struct pci_epf *epf = epf_test->epf;
+ struct pci_epc *epc = epf->epc;
+ struct pci_epf_bar *bar;
+ unsigned int nsub = PCI_EPF_TEST_BAR_SUBRANGE_NSUB, old_nsub;
+ /* reg->size carries BAR number for BAR_SUBRANGE_* commands. */
+ enum pci_barno barno = le32_to_cpu(reg->size);
+ u32 status = le32_to_cpu(reg->status);
+ unsigned int i, phys_idx;
+ size_t sub_size;
+ u8 *addr;
+ int ret;
+
+ if (barno >= PCI_STD_NUM_BARS) {
+ dev_err(&epf->dev, "Invalid barno: %d\n", barno);
+ goto err;
+ }
+
+ /* Host side should've avoided test_reg_bar, this is a safeguard. */
+ if (barno == epf_test->test_reg_bar) {
+ dev_err(&epf->dev, "test_reg_bar cannot be used for subrange test\n");
+ goto err;
+ }
+
+ if (!epf_test->epc_features->dynamic_inbound_mapping ||
+ !epf_test->epc_features->subrange_mapping) {
+ dev_err(&epf->dev, "epc driver does not support subrange mapping\n");
+ goto err;
+ }
+
+ bar = &epf->bar[barno];
+ if (!bar->size || !bar->addr) {
+ dev_err(&epf->dev, "bar size/addr (%zu/%p) is invalid\n",
+ bar->size, bar->addr);
+ goto err;
+ }
+
+ if (bar->size % nsub) {
+ dev_err(&epf->dev, "BAR size %zu is not divisible by %u\n",
+ bar->size, nsub);
+ goto err;
+ }
+
+ sub_size = bar->size / nsub;
+
+ submap = kcalloc(nsub, sizeof(*submap), GFP_KERNEL);
+ if (!submap)
+ goto err;
+
+ for (i = 0; i < nsub; i++) {
+ /* Swap the two halves so RC can verify ordering. */
+ phys_idx = i ^ 1;
+ submap[i].phys_addr = bar->phys_addr + (phys_idx * sub_size);
+ submap[i].size = sub_size;
+ }
+
+ old_submap = bar->submap;
+ old_nsub = bar->num_submap;
+
+ bar->submap = submap;
+ bar->num_submap = nsub;
+
+ ret = pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no, bar);
+ if (ret) {
+ dev_err(&epf->dev, "pci_epc_set_bar() failed: %d\n", ret);
+ bar->submap = old_submap;
+ bar->num_submap = old_nsub;
+ kfree(submap);
+ goto err;
+ }
+ kfree(old_submap);
+
+ /*
+ * Fill deterministic signatures into the physical regions that
+ * each BAR subrange maps to. RC verifies these to ensure the
+ * submap order is really applied.
+ */
+ addr = (u8 *)bar->addr;
+ for (i = 0; i < nsub; i++) {
+ phys_idx = i ^ 1;
+ memset(addr + (phys_idx * sub_size),
+ pci_epf_test_subrange_sig_byte(barno, i),
+ sub_size);
+ }
+
+ status |= STATUS_BAR_SUBRANGE_SETUP_SUCCESS;
+ reg->status = cpu_to_le32(status);
+ return;
+
+err:
+ status |= STATUS_BAR_SUBRANGE_SETUP_FAIL;
+ reg->status = cpu_to_le32(status);
+}
+
+static void pci_epf_test_bar_subrange_clear(struct pci_epf_test *epf_test,
+ struct pci_epf_test_reg *reg)
+{
+ struct pci_epf *epf = epf_test->epf;
+ struct pci_epf_bar_submap *submap;
+ struct pci_epc *epc = epf->epc;
+ /* reg->size carries BAR number for BAR_SUBRANGE_* commands. */
+ enum pci_barno barno = le32_to_cpu(reg->size);
+ u32 status = le32_to_cpu(reg->status);
+ struct pci_epf_bar *bar;
+ unsigned int nsub;
+ int ret;
+
+ if (barno >= PCI_STD_NUM_BARS) {
+ dev_err(&epf->dev, "Invalid barno: %d\n", barno);
+ goto err;
+ }
+
+ bar = &epf->bar[barno];
+ submap = bar->submap;
+ nsub = bar->num_submap;
+
+ if (!submap || !nsub)
+ goto err;
+
+ bar->submap = NULL;
+ bar->num_submap = 0;
+
+ ret = pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no, bar);
+ if (ret) {
+ bar->submap = submap;
+ bar->num_submap = nsub;
+ dev_err(&epf->dev, "pci_epc_set_bar() failed: %d\n", ret);
+ goto err;
+ }
+ kfree(submap);
+
+ status |= STATUS_BAR_SUBRANGE_CLEAR_SUCCESS;
+ reg->status = cpu_to_le32(status);
+ return;
+
+err:
+ status |= STATUS_BAR_SUBRANGE_CLEAR_FAIL;
+ reg->status = cpu_to_le32(status);
+}
+
static void pci_epf_test_cmd_handler(struct work_struct *work)
{
u32 command;
@@ -861,6 +1019,14 @@ static void pci_epf_test_cmd_handler(struct work_struct *work)
pci_epf_test_disable_doorbell(epf_test, reg);
pci_epf_test_raise_irq(epf_test, reg);
break;
+ case COMMAND_BAR_SUBRANGE_SETUP:
+ pci_epf_test_bar_subrange_setup(epf_test, reg);
+ pci_epf_test_raise_irq(epf_test, reg);
+ break;
+ case COMMAND_BAR_SUBRANGE_CLEAR:
+ pci_epf_test_bar_subrange_clear(epf_test, reg);
+ pci_epf_test_raise_irq(epf_test, reg);
+ break;
default:
dev_err(dev, "Invalid command 0x%x\n", command);
break;
@@ -933,6 +1099,10 @@ static void pci_epf_test_set_capabilities(struct pci_epf *epf)
if (epf_test->epc_features->intx_capable)
caps |= CAP_INTX;
+ if (epf_test->epc_features->dynamic_inbound_mapping &&
+ epf_test->epc_features->subrange_mapping)
+ caps |= CAP_SUBRANGE_MAPPING;
+
reg->caps = cpu_to_le32(caps);
}
--
2.51.0
^ permalink raw reply related [flat|nested] 19+ messages in thread* [PATCH v10 7/8] misc: pci_endpoint_test: Add BAR subrange mapping test case
2026-01-24 14:50 [PATCH v10 0/8] PCI: endpoint: BAR subrange mapping support Koichiro Den
` (5 preceding siblings ...)
2026-01-24 14:50 ` [PATCH v10 6/8] PCI: endpoint: pci-epf-test: Add BAR subrange mapping test support Koichiro Den
@ 2026-01-24 14:50 ` Koichiro Den
2026-01-24 14:50 ` [PATCH v10 8/8] selftests: pci_endpoint: " Koichiro Den
2026-01-28 13:47 ` [PATCH v10 0/8] PCI: endpoint: BAR subrange mapping support Manivannan Sadhasivam
8 siblings, 0 replies; 19+ messages in thread
From: Koichiro Den @ 2026-01-24 14:50 UTC (permalink / raw)
To: jingoohan1, mani, lpieralisi, kwilczynski, robh, bhelgaas, cassel,
Frank.Li
Cc: vigneshr, s-vadapalli, hongxing.zhu, l.stach, shawnguo, s.hauer,
kernel, festevam, minghuan.Lian, mingkai.hu, roy.zang,
jesper.nilsson, heiko, srikanth.thokala, marek.vasut+renesas,
yoshihiro.shimoda.uh, geert+renesas, magnus.damm, christian.bruel,
mcoquelin.stm32, alexandre.torgue, thierry.reding, jonathanh,
hayashi.kunihiko, mhiramat, kishon, jirislaby, rongqianfeng,
18255117159, shawn.lin, nicolas.frattaroli, linux.amoon, vidyas,
shuah, linux-omap, linux-pci, linux-arm-kernel, linux-kernel, imx,
linuxppc-dev, linux-arm-kernel, linux-rockchip, linux-arm-msm,
linux-renesas-soc, linux-stm32, linux-tegra, linux-kselftest
Add a new PCITEST_BAR_SUBRANGE ioctl to exercise EPC BAR subrange
mapping end-to-end.
The test programs a simple 2-subrange layout on the endpoint (via
pci-epf-test) and verifies that:
- the endpoint-provided per-subrange signature bytes are observed at
the expected PCIe BAR offsets, and
- writes to each subrange are routed to the correct backing region
(i.e. the submap order is applied rather than accidentally working
due to an identity mapping).
Return -EOPNOTSUPP when the endpoint does not advertise subrange
mapping, -ENODATA when the BAR is disabled, and -EBUSY when the BAR is
reserved for the test register space.
Signed-off-by: Koichiro Den <den@valinux.co.jp>
---
drivers/misc/pci_endpoint_test.c | 203 ++++++++++++++++++++++++++++++-
include/uapi/linux/pcitest.h | 1 +
2 files changed, 203 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
index 1c0fd185114f..74ab5b5b9011 100644
--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -39,6 +39,8 @@
#define COMMAND_COPY BIT(5)
#define COMMAND_ENABLE_DOORBELL BIT(6)
#define COMMAND_DISABLE_DOORBELL BIT(7)
+#define COMMAND_BAR_SUBRANGE_SETUP BIT(8)
+#define COMMAND_BAR_SUBRANGE_CLEAR BIT(9)
#define PCI_ENDPOINT_TEST_STATUS 0x8
#define STATUS_READ_SUCCESS BIT(0)
@@ -55,6 +57,10 @@
#define STATUS_DOORBELL_ENABLE_FAIL BIT(11)
#define STATUS_DOORBELL_DISABLE_SUCCESS BIT(12)
#define STATUS_DOORBELL_DISABLE_FAIL BIT(13)
+#define STATUS_BAR_SUBRANGE_SETUP_SUCCESS BIT(14)
+#define STATUS_BAR_SUBRANGE_SETUP_FAIL BIT(15)
+#define STATUS_BAR_SUBRANGE_CLEAR_SUCCESS BIT(16)
+#define STATUS_BAR_SUBRANGE_CLEAR_FAIL BIT(17)
#define PCI_ENDPOINT_TEST_LOWER_SRC_ADDR 0x0c
#define PCI_ENDPOINT_TEST_UPPER_SRC_ADDR 0x10
@@ -77,6 +83,7 @@
#define CAP_MSI BIT(1)
#define CAP_MSIX BIT(2)
#define CAP_INTX BIT(3)
+#define CAP_SUBRANGE_MAPPING BIT(4)
#define PCI_ENDPOINT_TEST_DB_BAR 0x34
#define PCI_ENDPOINT_TEST_DB_OFFSET 0x38
@@ -100,6 +107,8 @@
#define PCI_DEVICE_ID_ROCKCHIP_RK3588 0x3588
+#define PCI_ENDPOINT_TEST_BAR_SUBRANGE_NSUB 2
+
static DEFINE_IDA(pci_endpoint_test_ida);
#define to_endpoint_test(priv) container_of((priv), struct pci_endpoint_test, \
@@ -414,6 +423,193 @@ static int pci_endpoint_test_bars(struct pci_endpoint_test *test)
return 0;
}
+static u8 pci_endpoint_test_subrange_sig_byte(enum pci_barno barno,
+ unsigned int subno)
+{
+ return 0x50 + (barno * 8) + subno;
+}
+
+static u8 pci_endpoint_test_subrange_test_byte(enum pci_barno barno,
+ unsigned int subno)
+{
+ return 0xa0 + (barno * 8) + subno;
+}
+
+static int pci_endpoint_test_bar_subrange_cmd(struct pci_endpoint_test *test,
+ enum pci_barno barno, u32 command,
+ u32 ok_bit, u32 fail_bit)
+{
+ struct pci_dev *pdev = test->pdev;
+ struct device *dev = &pdev->dev;
+ int irq_type = test->irq_type;
+ u32 status;
+
+ if (irq_type < PCITEST_IRQ_TYPE_INTX ||
+ irq_type > PCITEST_IRQ_TYPE_MSIX) {
+ dev_err(dev, "Invalid IRQ type\n");
+ return -EINVAL;
+ }
+
+ reinit_completion(&test->irq_raised);
+
+ pci_endpoint_test_writel(test, PCI_ENDPOINT_TEST_STATUS, 0);
+ pci_endpoint_test_writel(test, PCI_ENDPOINT_TEST_IRQ_TYPE, irq_type);
+ pci_endpoint_test_writel(test, PCI_ENDPOINT_TEST_IRQ_NUMBER, 1);
+ /* Reuse SIZE as a command parameter: bar number. */
+ pci_endpoint_test_writel(test, PCI_ENDPOINT_TEST_SIZE, barno);
+ pci_endpoint_test_writel(test, PCI_ENDPOINT_TEST_COMMAND, command);
+
+ if (!wait_for_completion_timeout(&test->irq_raised,
+ msecs_to_jiffies(1000)))
+ return -ETIMEDOUT;
+
+ status = pci_endpoint_test_readl(test, PCI_ENDPOINT_TEST_STATUS);
+ if (status & fail_bit)
+ return -EIO;
+
+ if (!(status & ok_bit))
+ return -EIO;
+
+ return 0;
+}
+
+static int pci_endpoint_test_bar_subrange_setup(struct pci_endpoint_test *test,
+ enum pci_barno barno)
+{
+ return pci_endpoint_test_bar_subrange_cmd(test, barno,
+ COMMAND_BAR_SUBRANGE_SETUP,
+ STATUS_BAR_SUBRANGE_SETUP_SUCCESS,
+ STATUS_BAR_SUBRANGE_SETUP_FAIL);
+}
+
+static int pci_endpoint_test_bar_subrange_clear(struct pci_endpoint_test *test,
+ enum pci_barno barno)
+{
+ return pci_endpoint_test_bar_subrange_cmd(test, barno,
+ COMMAND_BAR_SUBRANGE_CLEAR,
+ STATUS_BAR_SUBRANGE_CLEAR_SUCCESS,
+ STATUS_BAR_SUBRANGE_CLEAR_FAIL);
+}
+
+static int pci_endpoint_test_bar_subrange(struct pci_endpoint_test *test,
+ enum pci_barno barno)
+{
+ u32 nsub = PCI_ENDPOINT_TEST_BAR_SUBRANGE_NSUB;
+ struct device *dev = &test->pdev->dev;
+ size_t sub_size, buf_size;
+ resource_size_t bar_size;
+ void __iomem *bar_addr;
+ void *read_buf = NULL;
+ int ret, clear_ret;
+ size_t off, chunk;
+ u32 i, exp, val;
+ u8 pattern;
+
+ if (!(test->ep_caps & CAP_SUBRANGE_MAPPING))
+ return -EOPNOTSUPP;
+
+ /*
+ * The test register BAR is not safe to reprogram and write/read
+ * over its full size. BAR_TEST already special-cases it to a tiny
+ * range. For subrange mapping tests, let's simply skip it.
+ */
+ if (barno == test->test_reg_bar)
+ return -EBUSY;
+
+ bar_size = pci_resource_len(test->pdev, barno);
+ if (!bar_size)
+ return -ENODATA;
+
+ bar_addr = test->bar[barno];
+ if (!bar_addr)
+ return -ENOMEM;
+
+ ret = pci_endpoint_test_bar_subrange_setup(test, barno);
+ if (ret)
+ return ret;
+
+ if (bar_size % nsub || bar_size / nsub > SIZE_MAX) {
+ ret = -EINVAL;
+ goto out_clear;
+ }
+
+ sub_size = bar_size / nsub;
+ if (sub_size < sizeof(u32)) {
+ ret = -ENOSPC;
+ goto out_clear;
+ }
+
+ /* Limit the temporary buffer size */
+ buf_size = min_t(size_t, sub_size, SZ_1M);
+
+ read_buf = kmalloc(buf_size, GFP_KERNEL);
+ if (!read_buf) {
+ ret = -ENOMEM;
+ goto out_clear;
+ }
+
+ /*
+ * Step 1: verify EP-provided signature per subrange. This detects
+ * whether the EP actually applied the submap order.
+ */
+ for (i = 0; i < nsub; i++) {
+ exp = (u32)pci_endpoint_test_subrange_sig_byte(barno, i) *
+ 0x01010101U;
+ val = ioread32(bar_addr + (i * sub_size));
+ if (val != exp) {
+ dev_err(dev,
+ "BAR%d subrange%u signature mismatch @%#zx: exp %#08x got %#08x\n",
+ barno, i, (size_t)i * sub_size, exp, val);
+ ret = -EIO;
+ goto out_clear;
+ }
+ val = ioread32(bar_addr + (i * sub_size) + sub_size - sizeof(u32));
+ if (val != exp) {
+ dev_err(dev,
+ "BAR%d subrange%u signature mismatch @%#zx: exp %#08x got %#08x\n",
+ barno, i,
+ ((size_t)i * sub_size) + sub_size - sizeof(u32),
+ exp, val);
+ ret = -EIO;
+ goto out_clear;
+ }
+ }
+
+ /* Step 2: write unique pattern per subrange (write all first). */
+ for (i = 0; i < nsub; i++) {
+ pattern = pci_endpoint_test_subrange_test_byte(barno, i);
+ memset_io(bar_addr + (i * sub_size), pattern, sub_size);
+ }
+
+ /* Step 3: read back and verify (read all after all writes). */
+ for (i = 0; i < nsub; i++) {
+ pattern = pci_endpoint_test_subrange_test_byte(barno, i);
+ for (off = 0; off < sub_size; off += chunk) {
+ void *bad;
+
+ chunk = min_t(size_t, buf_size, sub_size - off);
+ memcpy_fromio(read_buf, bar_addr + (i * sub_size) + off,
+ chunk);
+ bad = memchr_inv(read_buf, pattern, chunk);
+ if (bad) {
+ size_t bad_off = (u8 *)bad - (u8 *)read_buf;
+
+ dev_err(dev,
+ "BAR%d subrange%u data mismatch @%#zx (pattern %#02x)\n",
+ barno, i, (size_t)i * sub_size + off + bad_off,
+ pattern);
+ ret = -EIO;
+ goto out_clear;
+ }
+ }
+ }
+
+out_clear:
+ kfree(read_buf);
+ clear_ret = pci_endpoint_test_bar_subrange_clear(test, barno);
+ return ret ?: clear_ret;
+}
+
static int pci_endpoint_test_intx_irq(struct pci_endpoint_test *test)
{
u32 val;
@@ -936,12 +1132,17 @@ static long pci_endpoint_test_ioctl(struct file *file, unsigned int cmd,
switch (cmd) {
case PCITEST_BAR:
+ case PCITEST_BAR_SUBRANGE:
bar = arg;
if (bar <= NO_BAR || bar > BAR_5)
goto ret;
if (is_am654_pci_dev(pdev) && bar == BAR_0)
goto ret;
- ret = pci_endpoint_test_bar(test, bar);
+
+ if (cmd == PCITEST_BAR)
+ ret = pci_endpoint_test_bar(test, bar);
+ else
+ ret = pci_endpoint_test_bar_subrange(test, bar);
break;
case PCITEST_BARS:
ret = pci_endpoint_test_bars(test);
diff --git a/include/uapi/linux/pcitest.h b/include/uapi/linux/pcitest.h
index d6023a45a9d0..710f8842223f 100644
--- a/include/uapi/linux/pcitest.h
+++ b/include/uapi/linux/pcitest.h
@@ -22,6 +22,7 @@
#define PCITEST_GET_IRQTYPE _IO('P', 0x9)
#define PCITEST_BARS _IO('P', 0xa)
#define PCITEST_DOORBELL _IO('P', 0xb)
+#define PCITEST_BAR_SUBRANGE _IO('P', 0xc)
#define PCITEST_CLEAR_IRQ _IO('P', 0x10)
#define PCITEST_IRQ_TYPE_UNDEFINED -1
--
2.51.0
^ permalink raw reply related [flat|nested] 19+ messages in thread* [PATCH v10 8/8] selftests: pci_endpoint: Add BAR subrange mapping test case
2026-01-24 14:50 [PATCH v10 0/8] PCI: endpoint: BAR subrange mapping support Koichiro Den
` (6 preceding siblings ...)
2026-01-24 14:50 ` [PATCH v10 7/8] misc: pci_endpoint_test: Add BAR subrange mapping test case Koichiro Den
@ 2026-01-24 14:50 ` Koichiro Den
2026-01-28 13:47 ` [PATCH v10 0/8] PCI: endpoint: BAR subrange mapping support Manivannan Sadhasivam
8 siblings, 0 replies; 19+ messages in thread
From: Koichiro Den @ 2026-01-24 14:50 UTC (permalink / raw)
To: jingoohan1, mani, lpieralisi, kwilczynski, robh, bhelgaas, cassel,
Frank.Li
Cc: vigneshr, s-vadapalli, hongxing.zhu, l.stach, shawnguo, s.hauer,
kernel, festevam, minghuan.Lian, mingkai.hu, roy.zang,
jesper.nilsson, heiko, srikanth.thokala, marek.vasut+renesas,
yoshihiro.shimoda.uh, geert+renesas, magnus.damm, christian.bruel,
mcoquelin.stm32, alexandre.torgue, thierry.reding, jonathanh,
hayashi.kunihiko, mhiramat, kishon, jirislaby, rongqianfeng,
18255117159, shawn.lin, nicolas.frattaroli, linux.amoon, vidyas,
shuah, linux-omap, linux-pci, linux-arm-kernel, linux-kernel, imx,
linuxppc-dev, linux-arm-kernel, linux-rockchip, linux-arm-msm,
linux-renesas-soc, linux-stm32, linux-tegra, linux-kselftest
Add BAR_SUBRANGE_TEST to the pci_endpoint kselftest suite.
The test uses the PCITEST_BAR_SUBRANGE ioctl and will skip when the
chosen BAR is disabled (-ENODATA), when the endpoint/controller does not
support subrange mapping (-EOPNOTSUPP), or when the BAR is reserved for
the test register space (-EBUSY).
Signed-off-by: Koichiro Den <den@valinux.co.jp>
---
.../selftests/pci_endpoint/pci_endpoint_test.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/tools/testing/selftests/pci_endpoint/pci_endpoint_test.c b/tools/testing/selftests/pci_endpoint/pci_endpoint_test.c
index 23aac6f97061..eecb776c33af 100644
--- a/tools/testing/selftests/pci_endpoint/pci_endpoint_test.c
+++ b/tools/testing/selftests/pci_endpoint/pci_endpoint_test.c
@@ -70,6 +70,23 @@ TEST_F(pci_ep_bar, BAR_TEST)
EXPECT_FALSE(ret) TH_LOG("Test failed for BAR%d", variant->barno);
}
+TEST_F(pci_ep_bar, BAR_SUBRANGE_TEST)
+{
+ int ret;
+
+ pci_ep_ioctl(PCITEST_SET_IRQTYPE, PCITEST_IRQ_TYPE_AUTO);
+ ASSERT_EQ(0, ret) TH_LOG("Can't set AUTO IRQ type");
+
+ pci_ep_ioctl(PCITEST_BAR_SUBRANGE, variant->barno);
+ if (ret == -ENODATA)
+ SKIP(return, "BAR is disabled");
+ if (ret == -EBUSY)
+ SKIP(return, "BAR is test register space");
+ if (ret == -EOPNOTSUPP)
+ SKIP(return, "Subrange map is not supported");
+ EXPECT_FALSE(ret) TH_LOG("Test failed for BAR%d", variant->barno);
+}
+
FIXTURE(pci_ep_basic)
{
int fd;
--
2.51.0
^ permalink raw reply related [flat|nested] 19+ messages in thread* Re: [PATCH v10 0/8] PCI: endpoint: BAR subrange mapping support
2026-01-24 14:50 [PATCH v10 0/8] PCI: endpoint: BAR subrange mapping support Koichiro Den
` (7 preceding siblings ...)
2026-01-24 14:50 ` [PATCH v10 8/8] selftests: pci_endpoint: " Koichiro Den
@ 2026-01-28 13:47 ` Manivannan Sadhasivam
8 siblings, 0 replies; 19+ messages in thread
From: Manivannan Sadhasivam @ 2026-01-28 13:47 UTC (permalink / raw)
To: jingoohan1, lpieralisi, kwilczynski, robh, bhelgaas, cassel,
Frank.Li, Koichiro Den
Cc: vigneshr, s-vadapalli, hongxing.zhu, l.stach, shawnguo, s.hauer,
kernel, festevam, minghuan.Lian, mingkai.hu, roy.zang,
jesper.nilsson, heiko, srikanth.thokala, marek.vasut+renesas,
yoshihiro.shimoda.uh, geert+renesas, magnus.damm, christian.bruel,
mcoquelin.stm32, alexandre.torgue, thierry.reding, jonathanh,
hayashi.kunihiko, mhiramat, kishon, jirislaby, rongqianfeng,
18255117159, shawn.lin, nicolas.frattaroli, linux.amoon, vidyas,
shuah, linux-omap, linux-pci, linux-arm-kernel, linux-kernel, imx,
linuxppc-dev, linux-arm-kernel, linux-rockchip, linux-arm-msm,
linux-renesas-soc, linux-stm32, linux-tegra, linux-kselftest
On Sat, 24 Jan 2026 23:50:04 +0900, Koichiro Den wrote:
> This series proposes support for mapping subranges within a PCIe endpoint
> BAR and enables controllers to program inbound address translation for
> those subranges.
>
> Note: This series is a spin-off from a larger RFC series:
> https://lore.kernel.org/all/20260118135440.1958279-1-den@valinux.co.jp/
> The first user is the pci-endpoint-test, and the real user will
> likely be epf-vntb for Remote eDMA-backed NTB transport, demonstrated
> in that RFC series.
>
> [...]
Applied, thanks!
[1/8] PCI: endpoint: Add dynamic_inbound_mapping EPC feature
commit: 06a81c5940e46cc7bddee28f16bdd29a12a76344
[2/8] PCI: endpoint: Add BAR subrange mapping support
commit: 31fb95400451040050361e22ff480476964280f0
[3/8] PCI: dwc: Advertise dynamic inbound mapping support
commit: c0f1506f63546308e894469ceb0f1fadbdf9d2f9
[4/8] PCI: dwc: ep: Support BAR subrange inbound mapping via Address Match Mode iATU
commit: cfbc98dbf44d52738976f592f30c2ca6bb282939
[5/8] Documentation: PCI: endpoint: Clarify pci_epc_set_bar() usage
commit: 7d857a3f517df4591d4c85832c4ce5aeb0ddc038
[6/8] PCI: endpoint: pci-epf-test: Add BAR subrange mapping test support
commit: 530e3701a81b228c369261798ce1b7f63f5d6c08
[7/8] misc: pci_endpoint_test: Add BAR subrange mapping test case
commit: 622e1ad5e49c6949dd8c97d71f609bd17cfb8813
[8/8] selftests: pci_endpoint: Add BAR subrange mapping test case
commit: 0ebf8e7943e01b2c38c199228f51adbb89c02425
Best regards,
--
Manivannan Sadhasivam <mani@kernel.org>
^ permalink raw reply [flat|nested] 19+ messages in thread