Hello,
This v2 addresses some issues observed when running the ACPI probe
kselftest proposed in v1[1] across various devices and improves the overall
reliability of the test.
The acpi-extract-ids script has been improved to:
- Parse both .c and .h files
- Add an option to print only IDs matched by a driver (i.e. defined in an
ACPI match tables or in lists of IDs provided by the drivers)
The test_unprobed_devices.sh script relies on sysfs information to
determine if a device was successfully bound to a driver. Not all devices
listed in /sys/devices are expected to have a driver folder, so the script
has been adjusted to handle these cases and avoid generating false
negatives.
The test_unprobed_devices.sh test script logic has been modified to:
- Check the status attribute (when available) to exclusively test hardware
devices that are physically present, enabled and operational
- Traverse only ACPI objects with a physical_node* link, to ensure testing
of correctly enumerated devices
- Skip devices whose HID or CID are not matched by any driver, as
determined by the list generated through the acpi-extract-ids script
- Skip devices with HID or CID listed in the ignored IDs list. This list
has been added to contain IDs of devices that don't require a driver or
cannot be represented as platform devices (e.g. ACPI container and module
devices).
- Skip devices that are natively enumerated and don't need a driver, such
as certain PCI bridges
- Skip devices unassigned to any subsystem, devices linked to other devices
and class devices
Some of the heuristics used by the script are suboptimal and might require
adjustments over time. This kind of tests would greatly benefit from a
dedicated interface that exposes information about devices expected to be
matched by drivers and their probe status. Discussion regarding this matter
was initiated in v1.
As of now, I have not identified a suitable method for exposing this
information; I plan on submitting a separate RFC to propose some options
and engage in discussion. Meanwhile, this v2 focuses on utilizing already
available information to provide an ACPI equivalent of the existing DT
kselftest [2].
Adding in CC the people involved in the discussion at Plumbers [3], feel
free to add anyone that might be interested in this.
This series depends on:
- https://lore.kernel.org/all/[email protected]/T/#u
- https://lore.kernel.org/all/[email protected]/
Thanks,
Laura
[1] https://lore.kernel.org/all/[email protected]/T/
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/dt
[3] https://www.youtube.com/watch?v=oE73eVSyFXQ&t=9377s
Original cover letter:
Regressions that prevent a driver from probing a device can significantly
affect the functionality of a platform.
A kselftest to verify if devices on a DT-based platform are probed
correctly was recently introduced [4], but no such generic test is
available for ACPI platforms yet. bootrr [5] provides device probe
testing, but relies on a pre-defined list of the peripherals present on
each DUT.
On ACPI based hardware, a complete description of the platform is
provided to the OS by the system firmware. ACPI namespace objects are
mapped by the Linux ACPI subsystem into a device tree in
/sys/devices/LNXSYSTEM:00; the information in this subtree can be parsed
to build a list of the hw peripherals present on the DUT dynamically.
This series adds a test to verify if the devices declared in the ACPI
namespace and supported by the kernel are probed correctly.
This work follows a similar approach to [4], adapted for the ACPI use
case.
The first patch introduces a script that builds a list of all ACPI device
IDs supported by the kernel, by inspecting the acpi_device_id structs in
the sources. This list can be used to avoid testing ACPI-enumerated
devices that don't have a matching driver in the kernel. This script was
highly inspired by the dt-extract-compatibles script [6].
In the second patch, a new kselftest is added. It parses the
/sys/devices/LNXSYSTEM:00 tree to obtain a list of all platform
peripherals and verifies which of those, if supported, are correctly
bound to a driver.
Feedback is much appreciated,
Thank you,
Laura
[4] https://lore.kernel.org/all/[email protected]/
[5] https://github.com/kernelci/bootr
[6] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/dtc/dt-extract-compatibles
Laura Nao (2):
acpi: Add script to extract ACPI device ids in the kernel
kselftest: Add test to detect unprobed devices on ACPI platforms
MAINTAINERS | 2 +
scripts/acpi/acpi-extract-ids | 99 +++++++++++++
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/acpi/.gitignore | 1 +
tools/testing/selftests/acpi/Makefile | 21 +++
tools/testing/selftests/acpi/id_ignore_list | 3 +
.../selftests/acpi/test_unprobed_devices.sh | 138 ++++++++++++++++++
7 files changed, 265 insertions(+)
create mode 100755 scripts/acpi/acpi-extract-ids
create mode 100644 tools/testing/selftests/acpi/.gitignore
create mode 100644 tools/testing/selftests/acpi/Makefile
create mode 100644 tools/testing/selftests/acpi/id_ignore_list
create mode 100755 tools/testing/selftests/acpi/test_unprobed_devices.sh
--
2.30.2
Hi Shuah and Rafael,
On 3/8/24 15:49, Laura Nao wrote:
> Hello,
>
> This v2 addresses some issues observed when running the ACPI probe
> kselftest proposed in v1[1] across various devices and improves the overall
> reliability of the test.
>
> The acpi-extract-ids script has been improved to:
> - Parse both .c and .h files
> - Add an option to print only IDs matched by a driver (i.e. defined in an
> ACPI match tables or in lists of IDs provided by the drivers)
>
> The test_unprobed_devices.sh script relies on sysfs information to
> determine if a device was successfully bound to a driver. Not all devices
> listed in /sys/devices are expected to have a driver folder, so the script
> has been adjusted to handle these cases and avoid generating false
> negatives.
>
> The test_unprobed_devices.sh test script logic has been modified to:
> - Check the status attribute (when available) to exclusively test hardware
> devices that are physically present, enabled and operational
> - Traverse only ACPI objects with a physical_node* link, to ensure testing
> of correctly enumerated devices
> - Skip devices whose HID or CID are not matched by any driver, as
> determined by the list generated through the acpi-extract-ids script
> - Skip devices with HID or CID listed in the ignored IDs list. This list
> has been added to contain IDs of devices that don't require a driver or
> cannot be represented as platform devices (e.g. ACPI container and module
> devices).
> - Skip devices that are natively enumerated and don't need a driver, such
> as certain PCI bridges
> - Skip devices unassigned to any subsystem, devices linked to other devices
> and class devices
>
> Some of the heuristics used by the script are suboptimal and might require
> adjustments over time. This kind of tests would greatly benefit from a
> dedicated interface that exposes information about devices expected to be
> matched by drivers and their probe status. Discussion regarding this matter
> was initiated in v1.
>
> As of now, I have not identified a suitable method for exposing this
> information; I plan on submitting a separate RFC to propose some options
> and engage in discussion. Meanwhile, this v2 focuses on utilizing already
> available information to provide an ACPI equivalent of the existing DT
> kselftest [2].
>
> Adding in CC the people involved in the discussion at Plumbers [3], feel
> free to add anyone that might be interested in this.
>
> This series depends on:
> - https://lore.kernel.org/all/[email protected]/T/#u
> - https://lore.kernel.org/all/[email protected]/
>
> Thanks,
>
> Laura
>
> [1] https://lore.kernel.org/all/[email protected]/T/
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/dt
> [3] https://www.youtube.com/watch?v=oE73eVSyFXQ&t=9377s
Just wanted to gently check in on your thoughts regarding this series.
We've conducted some initial testing with it in KernelCI and it's proven
its worth by catching a driver probe regression [1] on some x86_64
platforms.
Your feedback would be greatly appreciated.
Thanks!
Laura
[1] https://lore.kernel.org/all/[email protected]/