On Mon, Mar 16, 2026 at 02:29:54PM +0100, Christian Bruel wrote:

On 3/16/26 13:57, Niklas Cassel wrote:

quoted

On Mon, Mar 16, 2026 at 01:41:03PM +0100, Christian Bruel wrote:

quoted

Hi Koichiro,

quoted

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.

quoted

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

quoted

Kind regards,
Niklas