On Fri, Mar 20, 2026 at 03:19:15PM +0100, Christian Bruel wrote:
>
>
> On 3/20/26 15:05, Koichiro Den wrote:
> > On Fri, Mar 20, 2026 at 11:04:28AM +0100, Christian Bruel wrote:
> > > Hello Koichiro, thank you for your comment
> > >
> > > On 3/19/26 02:28, Koichiro Den wrote:
> > > > On Wed, Mar 18, 2026 at 03:46:27PM +0100, Christian Bruel wrote:
> > > > > Handle -ENOSPC error. If the number of available inbound ATU entries
> > > > > is
> > > > > insufficient to map the subrange, skip the test instead of failing.
> > > > >
> > > > > Link:
> > > > > https://lore.kernel.org/linux-pci/20260317152707.GA85951@bhelgaas/T/#m87e4c24173097a0ea70195b71aab294ad8d6c283
> > > > > Signed-off-by: Christian Bruel <[email protected]>
> > > > > ---
> > > > > tools/testing/selftests/pci_endpoint/pci_endpoint_test.c | 2 ++
> > > > > 1 file changed, 2 insertions(+)
> > > > >
> > > > > diff --git a/tools/testing/selftests/pci_endpoint/pci_endpoint_test.c
> > > > > b/tools/testing/selftests/pci_endpoint/pci_endpoint_test.c
> > > > > index
> > > > > c417fb3a198b2d92c3060938c23807cc8bea5573..8ea2fda4539d11eb22b22800a7cb8bbaa99c91ba
> > > > > 100644
> > > > > --- a/tools/testing/selftests/pci_endpoint/pci_endpoint_test.c
> > > > > +++ b/tools/testing/selftests/pci_endpoint/pci_endpoint_test.c
> > > > > @@ -88,6 +88,8 @@ TEST_F(pci_ep_bar, BAR_SUBRANGE_TEST)
> > > > > SKIP(return, "Subrange map is not supported");
> > > > > if (ret == -ENOBUFS)
> > > > > SKIP(return, "BAR is reserved");
> > > > > + if (ret == -ENOSPC)
> > > > > + SKIP(return, "Not enough ATU entries to allocate
> > > > > subrange");
> > > >
> > > > Thank you for handling this!
> > > >
> > > > pci_endpoint_test_bar_subrange() can also return -ENOSPC locally:
> > > > https://github.com/torvalds/linux/blob/v7.0-rc4/drivers/misc/pci_endpoint_test.c#L538
> > > > While that is a different resource limit case, I think it would still be
> > > > reasonable to treat it as SKIP as well.
> > >
> > > Regarding Niklas's feedback to use the local EINVAL instead of ENOSPC in
> > > pci_endpoint_test_bar_subrange(), I prefer to leave this for you to
> > > handle.
> > > That will cover this case.
> >
> > So could you consider the following tiny patch as a prerequisite for your
> > series?
> > https://lore.kernel.org/linux-pci/[email protected]/
>
> sure, thank you
>
> >
> > >
> > > >
> > > > If you agree and keep your current approach, then I think the SKIP
> > > > message
> > > > might be better phrased more generically, e.g. "Insufficient resources".
> > >
> > > OK I agree, the error message should be less specific to DWC terminology,
> > > even though this case can currently only occur on it.
> >
> > Yes, I agree. As mentioned in my reply to Niklas, the other -ENOSPC is
> > better
> > replaced with -EINVAL, so I just submitted a tiny patch. That concern
> > should be
> > resolved.
> >
> > >
> > > >
> > > > If you prefer to keep that local case as FAIL (or at least distinguish
> > > > it
> > > > with a different SKIP message), that would likely require a bit more
> > > > changes overall. Note: Niklas' earlier feedback on the SKIP message
> > > > would
> > > > still apply.
> > >
> > > OK, as Niklas also suggested, I will not set an additional local bit
> > > besides
> > > the fail bit. The question is whether we should name it SKIP or NOSPC. I
> > > slightly prefer NOSPC, as this is what is used in the selftest to indicate
> > > skipping.
> >
> > Personally, Niklas' "errno in struct pci_epf_test_reg" idea sounds the best
> > among the options discussed so far.
>
> It is a good solution but does not match very well with the other existing
> API (See the STATUS_SRC/DST_ADDR_INVALID bits). Thus, we will keep the
> existing method of reporting errors using a second bit alongside the FAIL
> bit.
Understood. Thank you!
Koichiro
>
>
> >
> > Best regards,
> > Koichiro
> >
> > >
> > > thank you
> > >
> > > Christian
> > >
> > > >
> > > > Best regards,
> > > > Koichiro
> > > >
> > > > > EXPECT_FALSE(ret) TH_LOG("Test failed for BAR%d",
> > > > > variant->barno);
> > > > > }
> > > > >
> > > > > --
> > > > > 2.34.1
> > > > >
> > >
>
