public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Niklas Cassel <cassel@kernel.org>
To: Christian Bruel <christian.bruel@foss.st.com>
Cc: "Manivannan Sadhasivam" <mani@kernel.org>,
	"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
	"Kishon Vijay Abraham I" <kishon@kernel.org>,
	"Shuah Khan" <shuah@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Koichiro Den" <den@valinux.co.jp>,
	fabrice.gasnier@foss.st.com, linux-pci@vger.kernel.org,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] misc: pci_endpoint_test: Handle -ENOSPC in subrange mapping test case
Date: Wed, 18 Mar 2026 17:03:28 +0100	[thread overview]
Message-ID: <abrM0Jvo_sdWSTLc@ryzen> (raw)
In-Reply-To: <20260318-skip-bar_subrange-tests-if-enospc-v1-3-f1a49534ebea@foss.st.com>

On Wed, Mar 18, 2026 at 03:46:29PM +0100, Christian Bruel wrote:
> Return -ENOSPC instead of -EOI when the status reports the NOSPC bit.

s/EOI/EIO/


> This signifies to the pci_endpoint test to skip this test instead of
> reporting a failure.
> 
> Link: https://lore.kernel.org/linux-pci/20260317152707.GA85951@bhelgaas/T/#m87e4c24173097a0ea70195b71aab294ad8d6c283

I would drop the link.

I would put this patch after pci_epf_test.c patch and before selftest patch.


> Signed-off-by: Christian Bruel <christian.bruel@foss.st.com>
> ---
>  drivers/misc/pci_endpoint_test.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
> index 55e128ed82f00ae13b6fe9768cdbe56adbe8f9da..34ba06fb53f04e48c1c05f4aae85e6ecd03ef447 100644
> --- a/drivers/misc/pci_endpoint_test.c
> +++ b/drivers/misc/pci_endpoint_test.c
> @@ -61,6 +61,7 @@
>  #define STATUS_BAR_SUBRANGE_SETUP_FAIL		BIT(15)
>  #define STATUS_BAR_SUBRANGE_CLEAR_SUCCESS	BIT(16)
>  #define STATUS_BAR_SUBRANGE_CLEAR_FAIL		BIT(17)
> +#define STATUS_BAR_SUBRANGE_SETUP_NOSPC		BIT(18)
>  
>  #define PCI_ENDPOINT_TEST_LOWER_SRC_ADDR	0x0c
>  #define PCI_ENDPOINT_TEST_UPPER_SRC_ADDR	0x10
> @@ -476,8 +477,11 @@ static int pci_endpoint_test_bar_subrange_cmd(struct pci_endpoint_test *test,
>  		return -ETIMEDOUT;
>  
>  	status = pci_endpoint_test_readl(test, PCI_ENDPOINT_TEST_STATUS);
> -	if (status & fail_bit)
> +	if (status & fail_bit) {
> +		if (status & STATUS_BAR_SUBRANGE_SETUP_NOSPC)
> +			return -ENOSPC;

Perhaps this should be something like:

if (command == COMMAND_BAR_SUBRANGE_SETUP && status & STATUS_BAR_SUBRANGE_SETUP_SKIP)

Personally, I'm not a big fan of having a common function for both
pci_endpoint_test_bar_subrange_setup() and
pci_endpoint_test_bar_subrange_clear() and then sending in parameters
for which bits to check. It make it hard to have small differences
between them (like checking for an bit that is only valid for one of
the commands).

I can understand why Koichiro wrote it why he did, but since we now
want differences, perhaps add a preparation patch that makes it two
separate functions?

It is not like pci_endpoint_test_bar_subrange_cmd() is a big function
anyway.


Kind regards,
Niklas

  reply	other threads:[~2026-03-18 16:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-18 14:46 [PATCH 0/3] Skip subrange map tests on DWC iATU allocation failure Christian Bruel
2026-03-18 14:46 ` [PATCH 1/3] selftests: pci_endpoint: Skip subrange map test if iATU allocation fails Christian Bruel
2026-03-18 15:32   ` Niklas Cassel
2026-03-19  1:28   ` Koichiro Den
2026-03-19  8:47     ` Niklas Cassel
2026-03-20 13:41       ` Koichiro Den
2026-03-20 10:04     ` Christian Bruel
2026-03-20 14:05       ` Koichiro Den
2026-03-20 14:19         ` Christian Bruel
2026-03-20 15:33           ` Koichiro Den
2026-03-18 14:46 ` [PATCH 2/3] PCI: endpoint: pci-epf-test: Handle -ENOSPC in subrange map test Christian Bruel
2026-03-18 15:50   ` Niklas Cassel
2026-03-18 14:46 ` [PATCH 3/3] misc: pci_endpoint_test: Handle -ENOSPC in subrange mapping test case Christian Bruel
2026-03-18 16:03   ` Niklas Cassel [this message]
2026-03-20  9:35     ` Christian Bruel
2026-03-20 11:16       ` Niklas Cassel
2026-03-20 13:25         ` Christian Bruel
2026-03-20 13:43           ` Niklas Cassel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=abrM0Jvo_sdWSTLc@ryzen \
    --to=cassel@kernel.org \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=christian.bruel@foss.st.com \
    --cc=den@valinux.co.jp \
    --cc=fabrice.gasnier@foss.st.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kishon@kernel.org \
    --cc=kwilczynski@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mani@kernel.org \
    --cc=shuah@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox