host-tools: add Apps suspend resume host validation prototype

[smuppand]

Add a host-side Apps_Suspend_Resume test prototype for validating APPS suspend/resume using /sys/power/suspend_stats.

The test provides:

• host-side run.sh wrapper with repo-style .res result generation
• Python suspend/resume validator
• serial, SSH, and explicit ADB command transports
• TAC CLI based wake support for power-key, generic TAC wake, and USB control
• configurable power-key hold time in milliseconds
• configurable suspend, wake, resume, and settle timings
• boot_id comparison to detect reboot instead of resume
• PASS/FAIL/SKIP result handling through Apps_Suspend_Resume.res

This is intended for host-side/manual stabilization first, before adding a target-side LAVA-compatible suspend/resume test flow.

[mwasilew]

This won't work. You're trying to access server side configuration on the worker. It's just not there. If you want to run a test on the "host" side, it will run in a docker container with access to usb device (DUT). Nothing else will be available. For button presses (power on/ power off) there is no direct access from this container. It can only be executed as a "lava user command", example: https://lava.infra.foundries.io/scheduler/job/194340/definition#defline46

[mwasilew]

None of these are available on the worker.

[smuppand]

This won't work. You're trying to access server side configuration on the worker. It's just not there. If you want to run a test on the "host" side, it will run in a docker container with access to usb device (DUT). Nothing else will be available. For button presses (power on/ power off) there is no direct access from this container. It can only be executed as a "lava user command", example: https://lava.infra.foundries.io/scheduler/job/194340/definition#defline46

Agree. The host-side prototype incorrectly assumed that the test container could access LAVA server/device configuration or invoke TAC/button control directly. That is not valid for this setup, where the container only has access to the exposed DUT USB/serial devices.

I will drop the TAC serial discovery and direct tac-api/button control from the test script. For LAVA, I will rework this as a split flow:

1. a DUT-side prepare step records boot_id and /sys/power/suspend_stats, then schedules systemctl suspend and exits,
2. a LAVA user command performs the board-specific power-key wake action,
3. a DUT-side verify step resumes normal test execution, checks boot_id to reject reboot-as-resume, compares suspend_stats, and writes Apps_Suspend_Resume.res.

This keeps board-control operations in LAVA where they belong and keeps the test logic focused on APPS suspend/resume validation.

[mwasilew]

We can try that, but I'm pretty sure this won't work. There is no way to invoke a test shell in LAVA after resume. So the verification step should be run on the host, not on DUT.

I ran some tests yesterday and we're missing a few bits in the device dictionaries. Currently devices are not passed to the container properly. This is a separate issue, but it means that writing of this test needs to wait.

[mwasilew]

On a second thought, I think I was wrong assuming test shell can't run on resume. I'll add "short press" support in staging and we can try if it works.

[smuppand]

On a second thought, I think I was wrong assuming test shell can't run on resume. I'll add "short press" support in staging and we can try if it works.

Thanks for checking. That sounds good.

Once short-press support is available in staging, I can rework this PR away from the host-side TAC-control prototype and move to a LAVA-compatible DUT-side flow:

1. prepare phase runs on the DUT, records boot_id and /sys/power/suspend_stats, then schedules systemctl suspend and exits,
2. LAVA user command performs the board-specific short power-key press,
3. verify phase runs after resume, checks boot_id to reject reboot-as-resume, compares suspend_stats counters, and writes Apps_Suspend_Resume.res.

This should keep button control in LAVA where it belongs, while keeping the test logic focused only on APPS suspend/resume validation.

I will wait for the short-press staging support, then validate whether the post-resume test shell continues correctly before updating the PR.