cc @pauamma_gundo.com you had commented on the PR

nothing new from igor nor mandoc-lint.

ping @imp

apmd is still here

thanks for review

review

In D39965#916031, @markj wrote:

Looks like rc.suspend should be documented to some extent in rc.8, if anyone would like to take that on. rc.resume is at least mentioned there.

hi @markj, thanks for review.
feel free to commit if you are happy with this.

igor says:

$ igor -R -D -y share/man/man4/it8613hwm.4 | less -RS
it8613hwm.4 style check:
  "your" used 1 time
    "You" and "your" are informal and subjective.
    Attempt to be formal and objective: "the file" rather than "your file".
  "the following" used 5 times
    If something is following, the reader can see it without being told.

Those are in the license header and the synopsis blurp. which i copy-pasta'd from somewhere...

thanks @imp

style

In D39969#916811, @emaste wrote:

Can you please provide the author info as you'd like it to be, for git commit --author=...

hi @emaste, thanks for review.
feel free to commit if you are happy with this.

In D40139#915876, @markj wrote:

I think this is ok. It would be useful to have some motivation for the tunable: when should a user try it? Is there some risk involved?

less indent via elseif

use x86_msr_op

x86_msr_op looks much better and already does the right thing wrt unbind. thanks for the suggestion!

addressing review

addressing review

thanks for looking at the patch

synopsis for no options. make the other two non-optional.

review

style?

d and e option on separate lines

review comments.
i hope i got that right... man page diffs are surprisingly hard to read...

all refreshed into new patches and separated out.

cc @avg if you are still around

let me refresh this

feel free to commit if good to go

review

making sure to pick up the makefile as well

In D39961#909771, @christos wrote:

You also need to add:

MAN=	efiwake.8

to usr.sbin/efiwake/Makefile, otherwise the man page won't be installed.

review comments

linter is happy

address comments

thanks for looking at this patch

thanks for looking!

i've pretty much copy-pasted the added bits from rc.resume and adjusted the keyword. that's it.

cc @kib

@kib this came out of git-format-patch, does that look right?

review comments.
patch against current. compile-tested only.

In D36714#905557, @john.grafton_runbox.com wrote:

I tested this patch against CURRENT and the update wakes my generic AMD desktop at the specified time using efiwake.

review comments

In D36714#905278, @kib wrote:

In D36714#905228, @jo_bruelltuete.com wrote:

Thanks for reviewing!
Would be good to get folks to test this out on their hardware. I'm not sure what to make of the BIOS in my mainboard... it allows setting the wake timer, e.g. 2025-10-31T20:50:59, but ignores the month component! So you get a timer date of 2025-04-31T..., a date that does not exist. Or maybe I made a mistake somewhere...

Could you try to add printf()s in the kernel code right before SET_WAKETIME and after GET_WAKETIME efi_calls, to see what is the month value passed to/from UEFI RT methods. It might be not bios but some bug in userspace/kernel.

Thanks for reviewing!
Would be good to get folks to test this out on their hardware. I'm not sure what to make of the BIOS in my mainboard... it allows setting the wake timer, e.g. 2025-10-31T20:50:59, but ignores the month component! So you get a timer date of 2025-04-31T..., a date that does not exist. Or maybe I made a mistake somewhere...

addressing comments.
and found a weird bug in my bios...

Patch against current. I've checked that it compiles but cannot runtime test it.
The 13-stable version of this patch works fine on my hardware.

will update patch shortly.
meanwhile, got this in the console after (first) resume:

ACPI Error: No installed handler for fixed event - RealTimeClock (4), disabling (20201113/evevent-436)

Otherwise seems to be working fine.

thank you @pi!

@avg @pi new year new luck. can we commit this?

ping @avg or @imp: any thoughts here?
works fine for me. Most likely works with any IT87 chip (because thats the datasheet I found), but i only have it8613 to actually test on.

thanks for the pointer, kib!
spec looks relevant. but i have no idea how to do anything about those flags in the fbsd source code...

Hm... no idea how that is supposed to work then...
I suspect that something something ACPI needs to happen.
For example, for my NAS box I have (sysctl):

dev.acpi_sysresource.3.wake: 0

which is the super-io / power management controller (cf D36424).
But messing around with that wake parameter does not seem to do anything.

rebase onto current.
(compiles but not runtime tested)

hi @imp & @john.grafton_runbox.com, thanks for looking!
this patch was against stable-13. I don't have spare hardware to test on current...
how useful do you think this patch is? it did not actually work for me... i suspect a dodgy bios in the nas box, as it wakes from s5 but not from s3.

ping @avg -- please click the merge button if good to go.

Someone please click the merge button... thanks!

works pretty well, here's a grafana screenshot of the numbers that this driver spits out.

In D36495#836211, @jhb wrote:

Can you please confirm the e-mail address and name to use for the commit author when merging this?