linux-kernel - [PATCH v3 1/2] rtc-cmos: Clear ACPI-driven alarms upon resume

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20160914190841.10684-1-gabriele.mzt@gmail.com>
Date:   Wed, 14 Sep 2016 21:08:40 +0200
From:   Gabriele Mazzotta <gabriele.mzt@...il.com>
To:     alexandre.belloni@...e-electrons.com, a.zummo@...ertech.it
Cc:     rtc-linux@...glegroups.com, linux-kernel@...r.kernel.org,
        matthew.garrett@...ula.com,
        Gabriele Mazzotta <gabriele.mzt@...il.com>
Subject: [PATCH v3 1/2] rtc-cmos: Clear ACPI-driven alarms upon resume

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@...il.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