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

Christian Bruel
2026-03-18T08:03:10Z

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