Re: [RFC PATCH v2 0/2] Add a test to verify device probing on ACPI platforms

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]/