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

From: Niklas Cassel <[email-masked]>
Date: Mon, 16 Mar 2026 13:57:23 +0100

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