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=3D230290 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=3D195759&action= =3Dedit 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.=20 The problem is that acpi's ioctl requests sleep state directly, ignoring to invoke registered handlers. This patch will fix that.=20 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,=20 acpi_invoke_sleep_eventhandler, &state))) return ERROR; else=20 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] =3D {0,1,2,3,4,5} And pass &acpi_states[state] The purpose is to inform linuxkpi that we're suspending/resuming. For now t= he 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? --=20 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>