public inbox for kernelci@lists.linux.dev
 help / color / mirror / Atom feed
From: "Nícolas F. R. A. Prado" <nfraprado@collabora.com>
To: Shuah Khan <shuah@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Bjorn Helgaas <bhelgaas@google.com>
Cc: kernelci@lists.linux.dev, kernel@collabora.com,
	"Tim Bird" <Tim.Bird@sony.com>,
	linux-pci@vger.kernel.org, "David Gow" <davidgow@google.com>,
	linux-kselftest@vger.kernel.org,
	"Rob Herring" <robh+dt@kernel.org>,
	"Doug Anderson" <dianders@chromium.org>,
	linux-usb@vger.kernel.org,
	"Saravana Kannan" <saravanak@google.com>,
	"Dan Carpenter" <dan.carpenter@linaro.org>,
	"Guenter Roeck" <groeck@chromium.org>,
	devicetree@vger.kernel.org,
	"Nícolas F. R. A. Prado" <nfraprado@collabora.com>,
	linux-kernel@vger.kernel.org
Subject: [RFC PATCH v3 0/3] Add test to verify probe of devices from discoverable busses
Date: Wed, 27 Dec 2023 09:34:59 -0300	[thread overview]
Message-ID: <20231227123643.52348-1-nfraprado@collabora.com> (raw)


Hi,

for this v3 I changed the approach for identifying devices in a stable
way from the match fields back to the hardware topology (used in v1).
The match fields were proposed as a way to avoid the possible issue of
PCI topology being reconfigured, but that wasn't observed on any real
system so far. However using match fields does allow for a real issue if
an external device similar to an internal one is connected to the
system, which results in a change of the match count and therefore a
test failure. So using the HW topology was chosen as the most reliable
approach.

The per-platform device description file now uses YAML following a
suggestion from Chris Obbard, and the test script was re-written in
python to handle the new YAML format.

A second sample board file is also now included for an x86 platform,
which contains an USB controller behind a PCI controller, which wasn't
possible to describe in v1.

Thanks,
Nícolas

v2: https://lore.kernel.org/all/20231127233558.868365-1-nfraprado@collabora.com
v1: https://lore.kernel.org/all/20231024211818.365844-1-nfraprado@collabora.com

Original cover letter:

This is part of an effort to improve detection of regressions impacting
device probe on all platforms. The recently merged DT kselftest [3]
detects probe issues for all devices described statically in the DT.
That leaves out devices discovered at run-time from discoverable busses.

This is where this test comes in. All of the devices that are connected
through discoverable busses (ie USB and PCI), and which are internal and
therefore always present, can be described in a per-platform file so
they can be checked for. The test will check that the device has been
instantiated and bound to a driver.

Patch 1 introduces the test. Patch 2 and 3 add the device definitions
for the google,spherion machine (Acer Chromebook 514) and XPS 13 as
examples.

This is the output from the test running on Spherion:

TAP version 13
Using board file: boards/google,spherion.yaml
1..8
ok 1 /usb2-controller@11200000/1.4.1/camera.device
ok 2 /usb2-controller@11200000/1.4.1/camera.0.driver
ok 3 /usb2-controller@11200000/1.4.1/camera.1.driver
ok 4 /usb2-controller@11200000/1.4.2/bluetooth.device
ok 5 /usb2-controller@11200000/1.4.2/bluetooth.0.driver
ok 6 /usb2-controller@11200000/1.4.2/bluetooth.1.driver
ok 7 /pci-controller@11230000/0.0/0.0/wifi.device
ok 8 /pci-controller@11230000/0.0/0.0/wifi.driver
Totals: pass:8 fail:0 xfail:0 xpass:0 skip:0 error:0

[3] https://lore.kernel.org/all/20230828211424.2964562-1-nfraprado@collabora.com/

Changes in v3:
- Reverted approach of encoding stable device reference in test file
from device match fields (from modalias) back to HW topology (from v1)
- Changed board file description to YAML
- Rewrote test script in python to handle YAML and support x86 platforms

Changes in v2:
- Changed approach of encoding stable device reference in test file from
HW topology to device match fields (the ones from modalias)
- Better documented test format

Nícolas F. R. A. Prado (3):
  kselftest: Add test to verify probe of devices from discoverable
    busses
  kselftest: devices: Add sample board file for google,spherion
  kselftest: devices: Add sample board file for XPS 13 9300

 tools/testing/selftests/Makefile              |   1 +
 tools/testing/selftests/devices/Makefile      |   4 +
 .../devices/boards/Dell Inc.,XPS 13 9300.yaml |  40 +++
 .../devices/boards/google,spherion.yaml       |  50 +++
 tools/testing/selftests/devices/ksft.py       |  90 +++++
 .../devices/test_discoverable_devices.py      | 318 ++++++++++++++++++
 6 files changed, 503 insertions(+)
 create mode 100644 tools/testing/selftests/devices/Makefile
 create mode 100644 tools/testing/selftests/devices/boards/Dell Inc.,XPS 13 9300.yaml
 create mode 100644 tools/testing/selftests/devices/boards/google,spherion.yaml
 create mode 100644 tools/testing/selftests/devices/ksft.py
 create mode 100755 tools/testing/selftests/devices/test_discoverable_devices.py

-- 
2.43.0


             reply	other threads:[~2023-12-27 12:38 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-27 12:34 Nícolas F. R. A. Prado [this message]
2023-12-27 12:35 ` [RFC PATCH v3 1/3] kselftest: Add test to verify probe of devices from discoverable busses Nícolas F. R. A. Prado
2023-12-27 12:35 ` [RFC PATCH v3 2/3] kselftest: devices: Add sample board file for google,spherion Nícolas F. R. A. Prado
2023-12-27 12:35 ` [RFC PATCH v3 3/3] kselftest: devices: Add sample board file for XPS 13 9300 Nícolas F. R. A. Prado
2023-12-28 23:53 ` [RFC PATCH v3 0/3] Add test to verify probe of devices from discoverable busses Bjorn Helgaas
2023-12-29 12:33   ` Nícolas F. R. A. Prado
2024-01-02  7:45 ` Dan Carpenter
2024-01-02 13:12   ` Nícolas F. R. A. Prado
2024-01-04 14:54   ` Mark Brown

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=20231227123643.52348-1-nfraprado@collabora.com \
    --to=nfraprado@collabora.com \
    --cc=Tim.Bird@sony.com \
    --cc=bhelgaas@google.com \
    --cc=dan.carpenter@linaro.org \
    --cc=davidgow@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=groeck@chromium.org \
    --cc=kernel@collabora.com \
    --cc=kernelci@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=saravanak@google.com \
    --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