* [PATCH v3 1/2] rtc-cmos: Clear ACPI-driven alarms upon resume
@ 2016-09-14 19:08 Gabriele Mazzotta
2016-09-14 19:08 ` [PATCH v3 2/2] rtc-cmos: Restore alarm after resume Gabriele Mazzotta
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: Gabriele Mazzotta @ 2016-09-14 19:08 UTC (permalink / raw)
To: alexandre.belloni, a.zummo
Cc: rtc-linux, linux-kernel, matthew.garrett, Gabriele Mazzotta
Currently ACPI-driven alarms are not cleared when they wake the
system. As consequence, expired alarms must be manually cleared to
program a new alarm. Fix this by correctly handling ACPI-driven
alarms.
More specifically, the ACPI specification [1] provides for two
alternative implementations of the RTC. Depending on the
implementation, the driver either clear the alarm from the resume
callback or from ACPI interrupt handler:
- The platform has the RTC wakeup status fixed in hardware
(ACPI_FADT_FIXED_RTC is 0). In this case the driver can determine
if the RTC was the reason of the wakeup from the resume callback
by reading the RTC status register.
- The platform has no fixed hardware feature event bits. In this
case a GPE is used to wake the system and the driver clears the
alarm from its handler.
[1] http://www.acpi.info/DOWNLOADS/ACPI_5_Errata%20A.pdf
Signed-off-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
---
drivers/rtc/rtc-cmos.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index 1dec52f..6042257 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -939,6 +939,22 @@ static int cmos_resume(struct device *dev)
tmp &= ~RTC_AIE;
hpet_mask_rtc_irq_bit(RTC_AIE);
} while (mask & RTC_AIE);
+
+ if ((tmp & RTC_AIE) &&
+ !(acpi_gbl_FADT.flags & ACPI_FADT_FIXED_RTC)) {
+ acpi_status status;
+ acpi_event_status rtc_status;
+
+ status = acpi_get_event_status(ACPI_EVENT_RTC,
+ &rtc_status);
+ if (ACPI_FAILURE(status)) {
+ dev_err(dev, "Could not get RTC status\n");
+ } else if (rtc_status & ACPI_EVENT_FLAG_SET) {
+ tmp &= ~RTC_AIE;
+ CMOS_WRITE(tmp, RTC_CONTROL);
+ rtc_update_irq(cmos->rtc, 1, mask);
+ }
+ }
}
spin_unlock_irq(&rtc_lock);
@@ -976,6 +992,22 @@ static SIMPLE_DEV_PM_OPS(cmos_pm_ops, cmos_suspend, cmos_resume);
static u32 rtc_handler(void *context)
{
struct device *dev = context;
+ struct cmos_rtc *cmos = dev_get_drvdata(dev);
+ unsigned char rtc_control;
+ unsigned char rtc_intr;
+
+ spin_lock_irq(&rtc_lock);
+ if (!cmos_rtc.suspend_ctrl)
+ rtc_control = cmos_rtc.suspend_ctrl;
+ else
+ rtc_control = CMOS_READ(RTC_CONTROL);
+ if (rtc_control & RTC_AIE) {
+ cmos_rtc.suspend_ctrl &= ~RTC_AIE;
+ CMOS_WRITE(rtc_control, RTC_CONTROL);
+ rtc_intr = CMOS_READ(RTC_INTR_FLAGS);
+ rtc_update_irq(cmos->rtc, 1, rtc_intr);
+ }
+ spin_unlock_irq(&rtc_lock);
pm_wakeup_event(dev, 0);
acpi_clear_event(ACPI_EVENT_RTC);
--
2.9.3
^ permalink raw reply related [flat|nested] 5+ messages in thread
* [PATCH v3 2/2] rtc-cmos: Restore alarm after resume
2016-09-14 19:08 [PATCH v3 1/2] rtc-cmos: Clear ACPI-driven alarms upon resume Gabriele Mazzotta
@ 2016-09-14 19:08 ` Gabriele Mazzotta
2016-09-14 20:12 ` [PATCH v3 1/2] rtc-cmos: Clear ACPI-driven alarms upon resume kbuild test robot
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: Gabriele Mazzotta @ 2016-09-14 19:08 UTC (permalink / raw)
To: alexandre.belloni, a.zummo
Cc: rtc-linux, linux-kernel, matthew.garrett, Gabriele Mazzotta
Some platform firmware may interfere with the RTC alarm over suspend,
resulting in the kernel and hardware having different ideas about system
state but also potentially causing problems with firmware that assumes the
OS will clean this case up. This patch restores the RTC alarm on resume
to ensure that kernel and hardware are in sync.
The case we've seen is Intel Rapid Start, which is a firmware-mediated
feature that automatically transitions systems from suspend-to-RAM to
suspend-to-disk without OS involvement. It does this by setting the RTC
alarm and a flag that indicates that on wake it should perform the
transition rather than re-starting the OS. However, if the OS has set a
wakeup alarm that would wake the machine earlier, it refuses to overwrite
it and allows the system to wake instead.
This fails in the following situation:
1) User configures Intel Rapid Start to transition after (say) 15
minutes
2) User suspends to RAM. Firmware sets the wakeup alarm for 15 minutes
in the future
3) User resumes after 5 minutes. Firmware does not reset the alarm, and
as such it is still set for 10 minutes in the future
4) User suspends after 5 minutes. Firmware notices that the alarm is set
for 5 minutes in the future, which is less than the 15 minute transition
threshold. It therefore assumes that the user wants the machine to wake
in 5 minutes
5) System resumes after 5 minutes
The worst case scenario here is that the user may have put the system in a
bag between (4) and (5), resulting in it running in a confined space and
potentially overheating. This seems reasonably important. The Rapid
Start support code got added in 3.11, but it can be configured in the
firmware regardless of kernel support.
Signed-off-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
---
drivers/rtc/rtc-cmos.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index 6042257..5ca0945 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -62,6 +62,8 @@ struct cmos_rtc {
u8 day_alrm;
u8 mon_alrm;
u8 century;
+
+ struct rtc_wkalrm saved_wkalrm;
};
/* both platform and pnp busses use negative numbers for invalid irqs */
@@ -880,6 +882,8 @@ static int cmos_suspend(struct device *dev)
enable_irq_wake(cmos->irq);
}
+ cmos_read_alarm(dev, &cmos->saved_wkalrm);
+
dev_dbg(dev, "suspend%s, ctrl %02x\n",
(tmp & RTC_AIE) ? ", alarm may wake" : "",
tmp);
@@ -900,6 +904,22 @@ static inline int cmos_poweroff(struct device *dev)
#ifdef CONFIG_PM_SLEEP
+static void cmos_check_wkalrm(struct device *dev)
+{
+ struct cmos_rtc *cmos = dev_get_drvdata(dev);
+ struct rtc_wkalrm current_alarm;
+ time64_t t_current_expires;
+ time64_t t_saved_expires;
+
+ cmos_read_alarm(dev, ¤t_alarm);
+ t_current_expires = rtc_tm_to_time64(¤t_alarm.time);
+ t_saved_expires = rtc_tm_to_time64(&cmos->saved_wkalrm.time);
+ if (t_current_expires != t_saved_expires ||
+ cmos->saved_wkalrm.enabled != current_alarm.enabled) {
+ cmos_set_alarm(dev, &cmos->saved_wkalrm);
+ }
+}
+
static int cmos_resume(struct device *dev)
{
struct cmos_rtc *cmos = dev_get_drvdata(dev);
@@ -913,6 +933,9 @@ static int cmos_resume(struct device *dev)
cmos->enabled_wake = 0;
}
+ /* The BIOS might have changed the alarm, restore it */
+ cmos_check_wkalrm(dev);
+
spin_lock_irq(&rtc_lock);
tmp = cmos->suspend_ctrl;
cmos->suspend_ctrl = 0;
--
2.9.3
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH v3 1/2] rtc-cmos: Clear ACPI-driven alarms upon resume
2016-09-14 19:08 [PATCH v3 1/2] rtc-cmos: Clear ACPI-driven alarms upon resume Gabriele Mazzotta
2016-09-14 19:08 ` [PATCH v3 2/2] rtc-cmos: Restore alarm after resume Gabriele Mazzotta
@ 2016-09-14 20:12 ` kbuild test robot
2016-09-14 22:49 ` kbuild test robot
2016-09-19 22:21 ` Alexandre Belloni
3 siblings, 0 replies; 5+ messages in thread
From: kbuild test robot @ 2016-09-14 20:12 UTC (permalink / raw)
To: Gabriele Mazzotta
Cc: kbuild-all, alexandre.belloni, a.zummo, rtc-linux, linux-kernel,
matthew.garrett, Gabriele Mazzotta
[-- Attachment #1: Type: text/plain, Size: 4310 bytes --]
Hi Gabriele,
[auto build test ERROR on abelloni/rtc-next]
[also build test ERROR on v4.8-rc6 next-20160914]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
[Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url: https://github.com/0day-ci/linux/commits/Gabriele-Mazzotta/rtc-cmos-Clear-ACPI-driven-alarms-upon-resume/20160915-031802
base: https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git rtc-next
config: i386-defconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/rtc/rtc-cmos.c: In function 'cmos_resume':
>> drivers/rtc/rtc-cmos.c:941:9: error: 'acpi_gbl_FADT' undeclared (first use in this function)
!(acpi_gbl_FADT.flags & ACPI_FADT_FIXED_RTC)) {
^~~~~~~~~~~~~
drivers/rtc/rtc-cmos.c:941:9: note: each undeclared identifier is reported only once for each function it appears in
>> drivers/rtc/rtc-cmos.c:941:31: error: 'ACPI_FADT_FIXED_RTC' undeclared (first use in this function)
!(acpi_gbl_FADT.flags & ACPI_FADT_FIXED_RTC)) {
^~~~~~~~~~~~~~~~~~~
>> drivers/rtc/rtc-cmos.c:942:4: error: unknown type name 'acpi_status'
acpi_status status;
^~~~~~~~~~~
>> drivers/rtc/rtc-cmos.c:943:4: error: unknown type name 'acpi_event_status'
acpi_event_status rtc_status;
^~~~~~~~~~~~~~~~~
>> drivers/rtc/rtc-cmos.c:945:13: error: implicit declaration of function 'acpi_get_event_status' [-Werror=implicit-function-declaration]
status = acpi_get_event_status(ACPI_EVENT_RTC,
^~~~~~~~~~~~~~~~~~~~~
>> drivers/rtc/rtc-cmos.c:945:35: error: 'ACPI_EVENT_RTC' undeclared (first use in this function)
status = acpi_get_event_status(ACPI_EVENT_RTC,
^~~~~~~~~~~~~~
>> drivers/rtc/rtc-cmos.c:947:8: error: implicit declaration of function 'ACPI_FAILURE' [-Werror=implicit-function-declaration]
if (ACPI_FAILURE(status)) {
^~~~~~~~~~~~
>> drivers/rtc/rtc-cmos.c:949:28: error: 'ACPI_EVENT_FLAG_SET' undeclared (first use in this function)
} else if (rtc_status & ACPI_EVENT_FLAG_SET) {
^~~~~~~~~~~~~~~~~~~
In file included from include/acpi/acpi.h:64:0,
from include/linux/acpi.h:33,
from drivers/rtc/rtc-cmos.c:987:
include/acpi/acpixf.h: At top level:
>> include/acpi/acpixf.h:705:5: error: conflicting types for 'acpi_get_event_status'
acpi_get_event_status(u32 event,
^
include/acpi/acpixf.h:95:2: note: in definition of macro 'ACPI_EXTERNAL_RETURN_STATUS'
prototype;
^~~~~~~~~
include/acpi/acpixf.h:704:1: note: in expansion of macro 'ACPI_HW_DEPENDENT_RETURN_STATUS'
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/rtc/rtc-cmos.c:945:13: note: previous implicit declaration of 'acpi_get_event_status' was here
status = acpi_get_event_status(ACPI_EVENT_RTC,
^~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/acpi_gbl_FADT +941 drivers/rtc/rtc-cmos.c
935 rtc_update_irq(cmos->rtc, 1, mask);
936 tmp &= ~RTC_AIE;
937 hpet_mask_rtc_irq_bit(RTC_AIE);
938 } while (mask & RTC_AIE);
939
940 if ((tmp & RTC_AIE) &&
> 941 !(acpi_gbl_FADT.flags & ACPI_FADT_FIXED_RTC)) {
> 942 acpi_status status;
> 943 acpi_event_status rtc_status;
944
> 945 status = acpi_get_event_status(ACPI_EVENT_RTC,
946 &rtc_status);
> 947 if (ACPI_FAILURE(status)) {
948 dev_err(dev, "Could not get RTC status\n");
> 949 } else if (rtc_status & ACPI_EVENT_FLAG_SET) {
950 tmp &= ~RTC_AIE;
951 CMOS_WRITE(tmp, RTC_CONTROL);
952 rtc_update_irq(cmos->rtc, 1, mask);
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 24991 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v3 1/2] rtc-cmos: Clear ACPI-driven alarms upon resume
2016-09-14 19:08 [PATCH v3 1/2] rtc-cmos: Clear ACPI-driven alarms upon resume Gabriele Mazzotta
2016-09-14 19:08 ` [PATCH v3 2/2] rtc-cmos: Restore alarm after resume Gabriele Mazzotta
2016-09-14 20:12 ` [PATCH v3 1/2] rtc-cmos: Clear ACPI-driven alarms upon resume kbuild test robot
@ 2016-09-14 22:49 ` kbuild test robot
2016-09-19 22:21 ` Alexandre Belloni
3 siblings, 0 replies; 5+ messages in thread
From: kbuild test robot @ 2016-09-14 22:49 UTC (permalink / raw)
To: Gabriele Mazzotta
Cc: kbuild-all, alexandre.belloni, a.zummo, rtc-linux, linux-kernel,
matthew.garrett, Gabriele Mazzotta
[-- Attachment #1: Type: text/plain, Size: 6270 bytes --]
Hi Gabriele,
[auto build test WARNING on abelloni/rtc-next]
[also build test WARNING on v4.8-rc6 next-20160914]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
[Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url: https://github.com/0day-ci/linux/commits/Gabriele-Mazzotta/rtc-cmos-Clear-ACPI-driven-alarms-upon-resume/20160915-031802
base: https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git rtc-next
config: i386-randconfig-x0-09150359 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
In file included from include/linux/linkage.h:4:0,
from include/linux/kernel.h:6,
from drivers/rtc/rtc-cmos.c:34:
drivers/rtc/rtc-cmos.c: In function 'cmos_resume':
drivers/rtc/rtc-cmos.c:941:9: error: 'acpi_gbl_FADT' undeclared (first use in this function)
!(acpi_gbl_FADT.flags & ACPI_FADT_FIXED_RTC)) {
^
include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers/rtc/rtc-cmos.c:940:3: note: in expansion of macro 'if'
if ((tmp & RTC_AIE) &&
^~
drivers/rtc/rtc-cmos.c:941:9: note: each undeclared identifier is reported only once for each function it appears in
!(acpi_gbl_FADT.flags & ACPI_FADT_FIXED_RTC)) {
^
include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers/rtc/rtc-cmos.c:940:3: note: in expansion of macro 'if'
if ((tmp & RTC_AIE) &&
^~
drivers/rtc/rtc-cmos.c:941:31: error: 'ACPI_FADT_FIXED_RTC' undeclared (first use in this function)
!(acpi_gbl_FADT.flags & ACPI_FADT_FIXED_RTC)) {
^
include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers/rtc/rtc-cmos.c:940:3: note: in expansion of macro 'if'
if ((tmp & RTC_AIE) &&
^~
drivers/rtc/rtc-cmos.c:942:4: error: unknown type name 'acpi_status'
acpi_status status;
^~~~~~~~~~~
drivers/rtc/rtc-cmos.c:943:4: error: unknown type name 'acpi_event_status'
acpi_event_status rtc_status;
^~~~~~~~~~~~~~~~~
drivers/rtc/rtc-cmos.c:945:13: error: implicit declaration of function 'acpi_get_event_status' [-Werror=implicit-function-declaration]
status = acpi_get_event_status(ACPI_EVENT_RTC,
^~~~~~~~~~~~~~~~~~~~~
drivers/rtc/rtc-cmos.c:945:35: error: 'ACPI_EVENT_RTC' undeclared (first use in this function)
status = acpi_get_event_status(ACPI_EVENT_RTC,
^~~~~~~~~~~~~~
In file included from include/linux/linkage.h:4:0,
from include/linux/kernel.h:6,
from drivers/rtc/rtc-cmos.c:34:
drivers/rtc/rtc-cmos.c:947:8: error: implicit declaration of function 'ACPI_FAILURE' [-Werror=implicit-function-declaration]
if (ACPI_FAILURE(status)) {
^
include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
drivers/rtc/rtc-cmos.c:947:4: note: in expansion of macro 'if'
if (ACPI_FAILURE(status)) {
^~
drivers/rtc/rtc-cmos.c:949:28: error: 'ACPI_EVENT_FLAG_SET' undeclared (first use in this function)
} else if (rtc_status & ACPI_EVENT_FLAG_SET) {
^
include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
drivers/rtc/rtc-cmos.c:949:11: note: in expansion of macro 'if'
} else if (rtc_status & ACPI_EVENT_FLAG_SET) {
^~
In file included from include/acpi/acpi.h:64:0,
from include/linux/acpi.h:33,
from drivers/rtc/rtc-cmos.c:987:
include/acpi/acpixf.h: At top level:
include/acpi/acpixf.h:705:5: error: conflicting types for 'acpi_get_event_status'
acpi_get_event_status(u32 event,
^
include/acpi/acpixf.h:95:2: note: in definition of macro 'ACPI_EXTERNAL_RETURN_STATUS'
prototype;
^~~~~~~~~
include/acpi/acpixf.h:704:1: note: in expansion of macro 'ACPI_HW_DEPENDENT_RETURN_STATUS'
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/rtc/rtc-cmos.c:945:13: note: previous implicit declaration of 'acpi_get_event_status' was here
status = acpi_get_event_status(ACPI_EVENT_RTC,
^~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/if +940 drivers/rtc/rtc-cmos.c
924 CMOS_WRITE(tmp, RTC_CONTROL);
925 hpet_set_rtc_irq_bit(tmp & RTC_IRQMASK);
926
927 mask = CMOS_READ(RTC_INTR_FLAGS);
928 mask &= (tmp & RTC_IRQMASK) | RTC_IRQF;
929 if (!is_hpet_enabled() || !is_intr(mask))
930 break;
931
932 /* force one-shot behavior if HPET blocked
933 * the wake alarm's irq
934 */
935 rtc_update_irq(cmos->rtc, 1, mask);
936 tmp &= ~RTC_AIE;
937 hpet_mask_rtc_irq_bit(RTC_AIE);
938 } while (mask & RTC_AIE);
939
> 940 if ((tmp & RTC_AIE) &&
941 !(acpi_gbl_FADT.flags & ACPI_FADT_FIXED_RTC)) {
942 acpi_status status;
943 acpi_event_status rtc_status;
944
945 status = acpi_get_event_status(ACPI_EVENT_RTC,
946 &rtc_status);
947 if (ACPI_FAILURE(status)) {
948 dev_err(dev, "Could not get RTC status\n");
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 23196 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v3 1/2] rtc-cmos: Clear ACPI-driven alarms upon resume
2016-09-14 19:08 [PATCH v3 1/2] rtc-cmos: Clear ACPI-driven alarms upon resume Gabriele Mazzotta
` (2 preceding siblings ...)
2016-09-14 22:49 ` kbuild test robot
@ 2016-09-19 22:21 ` Alexandre Belloni
3 siblings, 0 replies; 5+ messages in thread
From: Alexandre Belloni @ 2016-09-19 22:21 UTC (permalink / raw)
To: Gabriele Mazzotta; +Cc: a.zummo, rtc-linux, linux-kernel, matthew.garrett
Hi Gabriele,
Thanks for your persistence! Both patches look good. Can you fix the
build issues reported by kbuild?
On 14/09/2016 at 21:08:40 +0200, Gabriele Mazzotta wrote :
> Currently ACPI-driven alarms are not cleared when they wake the
> system. As consequence, expired alarms must be manually cleared to
> program a new alarm. Fix this by correctly handling ACPI-driven
> alarms.
>
> More specifically, the ACPI specification [1] provides for two
> alternative implementations of the RTC. Depending on the
> implementation, the driver either clear the alarm from the resume
> callback or from ACPI interrupt handler:
>
> - The platform has the RTC wakeup status fixed in hardware
> (ACPI_FADT_FIXED_RTC is 0). In this case the driver can determine
> if the RTC was the reason of the wakeup from the resume callback
> by reading the RTC status register.
>
> - The platform has no fixed hardware feature event bits. In this
> case a GPE is used to wake the system and the driver clears the
> alarm from its handler.
>
> [1] http://www.acpi.info/DOWNLOADS/ACPI_5_Errata%20A.pdf
>
> Signed-off-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
> ---
> drivers/rtc/rtc-cmos.c | 32 ++++++++++++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
>
> diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
> index 1dec52f..6042257 100644
> --- a/drivers/rtc/rtc-cmos.c
> +++ b/drivers/rtc/rtc-cmos.c
> @@ -939,6 +939,22 @@ static int cmos_resume(struct device *dev)
> tmp &= ~RTC_AIE;
> hpet_mask_rtc_irq_bit(RTC_AIE);
> } while (mask & RTC_AIE);
> +
> + if ((tmp & RTC_AIE) &&
> + !(acpi_gbl_FADT.flags & ACPI_FADT_FIXED_RTC)) {
> + acpi_status status;
> + acpi_event_status rtc_status;
> +
> + status = acpi_get_event_status(ACPI_EVENT_RTC,
> + &rtc_status);
> + if (ACPI_FAILURE(status)) {
> + dev_err(dev, "Could not get RTC status\n");
> + } else if (rtc_status & ACPI_EVENT_FLAG_SET) {
> + tmp &= ~RTC_AIE;
> + CMOS_WRITE(tmp, RTC_CONTROL);
> + rtc_update_irq(cmos->rtc, 1, mask);
> + }
> + }
> }
> spin_unlock_irq(&rtc_lock);
>
> @@ -976,6 +992,22 @@ static SIMPLE_DEV_PM_OPS(cmos_pm_ops, cmos_suspend, cmos_resume);
> static u32 rtc_handler(void *context)
> {
> struct device *dev = context;
> + struct cmos_rtc *cmos = dev_get_drvdata(dev);
> + unsigned char rtc_control;
> + unsigned char rtc_intr;
> +
> + spin_lock_irq(&rtc_lock);
> + if (!cmos_rtc.suspend_ctrl)
> + rtc_control = cmos_rtc.suspend_ctrl;
> + else
> + rtc_control = CMOS_READ(RTC_CONTROL);
> + if (rtc_control & RTC_AIE) {
> + cmos_rtc.suspend_ctrl &= ~RTC_AIE;
> + CMOS_WRITE(rtc_control, RTC_CONTROL);
> + rtc_intr = CMOS_READ(RTC_INTR_FLAGS);
> + rtc_update_irq(cmos->rtc, 1, rtc_intr);
> + }
> + spin_unlock_irq(&rtc_lock);
>
> pm_wakeup_event(dev, 0);
> acpi_clear_event(ACPI_EVENT_RTC);
> --
> 2.9.3
>
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-09-19 22:21 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-09-14 19:08 [PATCH v3 1/2] rtc-cmos: Clear ACPI-driven alarms upon resume Gabriele Mazzotta
2016-09-14 19:08 ` [PATCH v3 2/2] rtc-cmos: Restore alarm after resume Gabriele Mazzotta
2016-09-14 20:12 ` [PATCH v3 1/2] rtc-cmos: Clear ACPI-driven alarms upon resume kbuild test robot
2016-09-14 22:49 ` kbuild test robot
2016-09-19 22:21 ` Alexandre Belloni
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).