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

[Koichiro Den]

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.

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).

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

Thanks,
Koichiro

> 
> 
> Kind regards,
> Niklas