| Message ID | 20240308144933.337107-1-laura.nao@collabora.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add a test to verify device probing on ACPI platforms | expand |
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/T/#u > - https://lore.kernel.org/all/20240131-ktap-sh-helpers-extend-v1-0-98ffb468712c@collabora.com/ > > Thanks, > > Laura > > [1] https://lore.kernel.org/all/20230925155806.1812249-2-laura.nao@collabora.com/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/20240530153727.843378-1-laura.nao@collabora.com/