Re: [PATCH 3/3] misc: pci_endpoint_test: Handle -ENOSPC in subrange mapping test case

[Niklas Cassel <cassel@kernel.org>]

On Fri, Mar 20, 2026 at 02:25:10PM +0100, Christian Bruel wrote:
> On 3/20/26 12:16, Niklas Cassel wrote:
> > 
> > FWIW, I think an even better solution is to introduce a new register,
> > named e.g. errno in struct pci_epf_test_reg;
> > 
> > That way, we don't need to take a new bit, e.g.:
> > +#define STATUS_BAR_SUBRANGE_SETUP_NOSPC          BIT(18)
> > 
> > For every unique error code a command can return.
> > 
> > We would simply return STATUS_BAR_SUBRANGE_CLEAR_FAIL, and then the host
> > side driver looks at the errno register to see the specific error code.
> > 
> > This way, all other _FAIL commands could also return a more specific error
> > in case of failure.

(snip)

> But it is not consistent with other tests that use the status field to carry
> error information. For example, pci_epf_test_read/write/copy, set the
> STATUS_SRC/DTS_ADDR_INVALID bit to distinguish these errors from other
> -EINVAL.
> 
> Introducing a new errno field would result in having two different APIs for
> returning failure status.
> 
> In light of the STATUS_SRC/DST_ADDR_INVALID usage, I wonder if my initial
> proposal to set a status bit along with the FAIL bit might actually be
> simpler and more consistent what is already done here.

You are right that the read/write/copy tests actually set two bits in the
status register.

With:
#define STATUS_SRC_ADDR_INVALID         BIT(7)
#define STATUS_DST_ADDR_INVALID         BIT(8)

Potentially being reused by the write/copy/read tests.

At least these bits are reuse for more than one test case.

So, perhaps to keep things in line with the existing design
perhaps just name the new bit something like:

#define STATUS_SKIP_INSUFFICIENT_RESOURCES	BIT(18)

or something like that.

At least then, other test cases will be able to reuse this status bit,
just like multiple test cases can use the STATUS_SRC_ADDR_INVALID status
bits.


And yes, I agree that, like you do in your initial proposal, having this
new STATUS_SKIP_INSUFFICIENT_RESOURCES bit set in addition to the
STATUS_BAR_SUBRANGE_CLEAR_FAIL bit, is probably the best way forward that
is in line with the current design.


Kind regards,
Niklas