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

[Christian Bruel]

On 3/17/26 16:14, Koichiro Den wrote:
> On Tue, Mar 17, 2026 at 11:46:03AM +0100, Niklas Cassel wrote:
> > On Tue, Mar 17, 2026 at 11:29:41AM +0100, Christian Bruel wrote:
> > > On 3/17/26 11:12, Niklas Cassel wrote:
> > > > On Tue, Mar 17, 2026 at 11:01:28AM +0100, Christian Bruel wrote:
> > > > > > So we will need to add a SKIP ENOSPC case in TEST_F(pci_ep_bar,
> > > > > > BAR_SUBRANGE_TEST)
> > > > > Re-checking this, no need for ENOSPC test. The real condition would be
> > > > > EBUSY. Which can be handled nicely in a stm32 ep_map_addr helper.
> > > >
> > > > Are you sure that it returns EBUSY and not ENOSPC?
> > > >
> > > > I would have expected the error to be ENOSPC when there are no free inbound
> > > > window:
> > > > https://github.com/torvalds/linux/blob/v7.0-rc4/drivers/pci/controller/dwc/pcie-designware-ep.c#L307-L312
> > >
> > > dw_pcie_ep_ib_atu_addr() returns ENOSPC. I was thinking to overload .set_bar
> > > with a stm32 helper to return EBUSY if the subrange bar is already reserved.
> > >
> > > So whatever is best
> > >   - modify TEST_F to SKIP if ENOSPC
> > > or
> > >   - Add a specific platform .set_bar helper to return EBUSY, already handled
> > > in the test.
> >
> > I think "modify TEST_F to SKIP if ENOSPC",
> > since it will solve the problem for all platforms that have few inbound iATUs.
>
> That sounds like the right direction, though I think we would first need a way
> to propagate -ENOSPC back to the host side, instead of just collapsing all
> EP-side setup failures into STATUS_BAR_SUBRANGE_SETUP_FAIL, which
> pci_endpoint_test currently maps to -EIO.

I think the epf test function can return several bits in the status 
mask, in addition of STATUS_BAR_SUBRANGE_SETUP_FAIL. e.g 
STATUS_BAR_SUBRANGE_SETUP_SKIP, or STATUS_BAR_SUBRANGE_SETUP_NOSPC.
I prefer the former since we want to pass the cause, not the action and 
let the skip decision to the host

> One question is whether it's always safe to treat -ENOSPC as a pure resource
> limitation, rather than something that could also be triggered by other issues
> (e.g. a bug).

Looking at the execution path, it seems that the only ENOSPC return 
point for the DWC controller is from dw_pcie_ep_ib_atu_addr() during 
allocation in the ib_window_map. If there is a bug in this part I 
expected it would be caught by the BAR_TEST

> That said, if preferred, I can prepare a patch (series) for that.
>
> Thanks,
> Koichiro

Oh, sorry, I'm already testing the patch.

thank you,

Christian

> > Kind regards,
> > Niklas