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/20240102141528.169947-1-laura.nao@collabora.com/...
- https://lore.kernel.org/all/20240131-ktap-sh-helpers-extend-v1-0-98ffb468712...
Thanks,
Laura
[1] https://lore.kernel.org/all/20230925155806.1812249-2-laura.nao@collabora.com... [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tool... [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/20240530153727.843378-1-laura.nao@collabora.com/