I'll check in a powerd change to make it easy to check if dark resume, formerly called lucid sleep, is enabled. (Hmm. It'd be good to rename this label too.)

This label currently hardcodes samus and lulu, but I see the following boards configured to use dark resume:

elm
link
lulu (disabled)
oak (disabled)
parrot
samus (disabled)

Will changing the label to accurately reflect the powerd config cause problems, since it'll change where some existing tests do or don't get run?

If I understand correctly, your change will have the 'lucidsleep' label only apply to elm, link and parrot (and remove it from samus/lulu)?

Yeah that will probably cause problems, I'd check on the test writers who use that label to see if the targets should change.  Here's a list of tests that use the label:

$ grep -rni lucidsleep . | grep DEPENDENCIES --include=*control*
./server/site_tests/network_WiFi_FastReconnectInDarkResume/control:9:DEPENDENCIES = 'servo, wificell, lucidsleep'
./server/site_tests/network_WiFi_WakeOnWiFiThrottling/control:9:DEPENDENCIES = 'servo, wificell, lucidsleep'
./server/site_tests/network_WiFi_ReconnectInDarkResume/control.DisconnectAfterSuspendSameAP:11:DEPENDENCIES = 'wificell, servo, lucidsleep'
./server/site_tests/network_WiFi_ReconnectInDarkResume/control.Stress:9:DEPENDENCIES = 'servo, wificell, lucidsleep'
./server/site_tests/network_WiFi_ReconnectInDarkResume/control.DisconnectBeforeSuspendSameAP:9:DEPENDENCIES = 'servo, wificell, lucidsleep'
./server/site_tests/network_WiFi_ReconnectInDarkResume/control.DisconnectAfterSuspendDiffAP:11:DEPENDENCIES = 'wificell, servo, lucidsleep'
./server/site_tests/network_WiFi_ReconnectInDarkResume/control.DisconnectBeforeSuspendDiffAP:9:DEPENDENCIES = 'servo, wificell, lucidsleep'
./server/site_tests/network_WiFi_WakeOnSSID/control:11:DEPENDENCIES = 'wificell, servo, lucidsleep'
./server/site_tests/network_WiFi_WakeOnDisconnect/control:11:DEPENDENCIES = 'wificell, servo, lucidsleep'
./server/site_tests/network_WiFi_DarkResumeActiveScans/control:11:DEPENDENCIES = 'wificell, servo, lucidsleep'
./server/site_tests/network_WiFi_WoWLAN/control:11:DEPENDENCIES = 'wificell, servo, lucidsleep'

Sigh. I don't even understand how those tests work at all if they depend on dark resume but only run on two boards where it's been disabled.

> Sigh. I don't even understand how those tests work
> at all if they depend on dark resume but only run
> on two boards where it's been disabled.

As best I can tell, they don't, they know it, and they
even say so:
    https://wmatrix.googleplex.com/failures/unfiltered?suites=wifi_lucidsleep&builds=R54-8628.0.0&releases=tot&platforms=lulu

:-(

I've sent out changes to introduce a new (accurate) dark_resume label that we can move tests over to.

Did anyone ever get a proper dark_resume label? Those 2 hardcoded boards still don't have it enabled, but I think there's some work going on for adding new ones.

Considering the test throws TestNA appropriately, we could remove the label usage entirely :)

Or can we do the same thing that lucid_sleep_test_base.py does, and check for wifi_client:is_wake_on_wifi_supported()?

Also, this:

https://chromium-review.googlesource.com/#/c/chromiumos/third_party/autotest/+/679935

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/42099294451201338cedce544535ddbf44e9b61a

commit 42099294451201338cedce544535ddbf44e9b61a
Author: Brian Norris <briannorris@chromium.org>
Date: Mon Sep 25 22:52:46 2017

cros_host: remove dead lucid-sleep code

Not used. And we have wifi_client:is_wake_on_wifi_supported() for
determining essentially the same thing.

BUG=chromium:592146
TEST=suite:wifi_lucidsleep

Change-Id: I67ed7ecbc7bdb5e3167ed0b749163d3647fb571d
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/679935
Reviewed-by: Eric Caruso <ejcaruso@chromium.org>

[modify] https://crrev.com/42099294451201338cedce544535ddbf44e9b61a/server/hosts/cros_host.py

Hi, this bug has not been updated recently. Please acknowledge the bug and provide status within two weeks (6/22/2018), or the bug will be archived. Thank you.

I don't think that this is particularly relevant anymore. If anyone else wants to take it over, feel free to reopen and reassign.

Ahem, Ravi is reviving these tests, so I think the TODO is still alive:

https://chromium-review.googlesource.com/c/chromiumos/third_party/autotest/+/1316341