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

Koichiro Den
2026-03-16T13:51:30Z

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
>