Re: [PATCH v10 3/8] PCI: dwc: Advertise dynamic inbound mapping support

Koichiro Den
2026-03-14T04:33:49Z

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