Re: [PATCH] PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails

[Niklas Cassel <cassel@kernel.org>]

On Tue, Mar 17, 2026 at 10:13:52AM +0100, Christian Bruel wrote:
> 
> Tested-by: Christian Bruel <christian.bruel@foss.st.com>
> 
> with the DISABLE BAR dependency
> https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/commit/?h=endpoint&id=33642e9e36dc084e4fc9245a266c9843bc8303b9
> 
> I will need to update the pci_epc_features after the merge.

I don't think you should update pci_epc_features just to be able to test
the inbound submapping feature.

As I said before, I think a better option would to ensure that the test is
skipped instead of returning failure, for SoCs with too few inbound iATUs.

A real EPF driver (not the test driver), that wants to run on STM32, and
wants to use inbound submapping feature, can simply ensure that it does not
enable all BARs (the test driver obviously enables all BARs, since it wants
to test all BARs). That way, that EPF driver will be able to use multiple
iATUs for a single BAR (as required by this new feature).

This works because all BARs are disabled by default. An EPF driver has to
enable the BARs it wants to use. (E.g. nvmet-pci-epf only enables BAR0.)


> 
> A more general question: I don't understand why only the STM32 is impacted.
> It seems that all targets, even those with 6 IB iATU entries, should ensure
> that one BAR is disabled to handle subranges.

I can't speak for every SoC, but looking at dmesg:
rockchip-dw-pcie a40000000.pcie-ep: iATU: unroll T, 16 ob, 16 ib, align 64K, limit 8G

rk3588 has 16 inbound windows.

Probably most SoCs have more than 6 ib windows?


Kind regards,
Niklas