Date: Thu, 02 Aug 2018 09:15:19 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 230290] [patch] acpi: call sleep event handler when sleeping via command line Message-ID: <bug-230290-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230290 Bug ID: 230290 Summary: [patch] acpi: call sleep event handler when sleeping via command line Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: johalun0@gmail.com CC: hps@FreeBSD.org Created attachment 195759 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=195759&action=edit Patch for acpi.c When adding listeners to acpi_sleep_event I realized that suspend via lid/button does not behave the same way as suspend via zzz or acpiconf. The problem is that acpi's ioctl requests sleep state directly, ignoring to invoke registered handlers. This patch will fix that. The drawback of this patch is that we have no chance to return an error from the ioctl call. To do that we need to do something like if (ACPI_FAILURE(AcpiOsExecute(OSL_NOTIFY_HANDLER, acpi_invoke_sleep_eventhandler, &state))) return ERROR; else return 0; However, 'state' in this case does not live long enough to be passed to the event handler so we need to add something like: static int acpi_states[6] = {0,1,2,3,4,5} And pass &acpi_states[state] The purpose is to inform linuxkpi that we're suspending/resuming. For now the power_suspend_early event is used but that does not include what state we're suspending to so we're forced to assume we're always suspending to S3. Which would be more preferable? -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-230290-227>