public inbox for linux-pci@vger.kernel.org
 help / color / mirror / Atom feed
From: Niklas Cassel <cassel@kernel.org>
To: bhelgaas@google.com, kw@linux.com
Cc: linux-pci@vger.kernel.org, shuah@kernel.org,
	linux-kselftest@vger.kernel.org,
	manivannan.sadhasivam@linaro.org,
	Niklas Cassel <cassel@kernel.org>
Subject: [PATCH 2/2] selftests: pci_endpoint: Skip disabled BARs
Date: Thu, 23 Jan 2025 13:01:49 +0100	[thread overview]
Message-ID: <20250123120147.3603409-4-cassel@kernel.org> (raw)
In-Reply-To: <20250123120147.3603409-3-cassel@kernel.org>

Currently BARs that have been disabled by the endpoint controller driver
will result in a test FAIL.

Returning FAIL for a BAR that is disabled seems overly pessimistic.

There are EPC that disables one or more BARs intentionally.

One reason for this is that there are certain EPCs that are hardwired to
expose internal PCIe controller registers over a certain BAR, so the EPC
driver disables such a BAR, such that the host will not overwrite random
registers during testing.

Such a BAR will be disabled by the EPC driver's init function, and the
BAR will be marked as BAR_RESERVED, such that it will be unavailable to
endpoint function drivers.

Let's return FAIL only for BARs that are actually enabled and failed the
test, and let's return skip for BARs that are not even enabled.

Signed-off-by: Niklas Cassel <cassel@kernel.org>
---
 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 c267b822c108..576c590b277b 100644
--- a/tools/testing/selftests/pci_endpoint/pci_endpoint_test.c
+++ b/tools/testing/selftests/pci_endpoint/pci_endpoint_test.c
@@ -65,6 +65,8 @@ TEST_F(pci_ep_bar, BAR_TEST)
 	int ret;
 
 	pci_ep_ioctl(PCITEST_BAR, variant->barno);
+	if (ret == -ENODATA)
+		SKIP(return, "BAR is disabled");
 	EXPECT_FALSE(ret) TH_LOG("Test failed for BAR%d", variant->barno);
 }
 
-- 
2.48.1


  reply	other threads:[~2025-01-23 12:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-23 12:01 [PATCH 1/2] misc: pci_endpoint_test: Give disabled BARs a distinct error code Niklas Cassel
2025-01-23 12:01 ` Niklas Cassel [this message]
2025-02-03 16:49   ` [PATCH 2/2] selftests: pci_endpoint: Skip disabled BARs Manivannan Sadhasivam
2025-02-14 17:45   ` Manivannan Sadhasivam
2025-01-27 16:31 ` [PATCH 1/2] misc: pci_endpoint_test: Give disabled BARs a distinct error code Niklas Cassel
2025-02-03 16:46 ` Manivannan Sadhasivam
2025-02-13 13:48 ` Niklas Cassel
2025-02-14 17:44 ` Manivannan Sadhasivam

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=20250123120147.3603409-4-cassel@kernel.org \
    --to=cassel@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=kw@linux.com \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=manivannan.sadhasivam@linaro.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