@@ -71,11 +71,16 @@ static ssize_t test_irq_store(struct device *dev,
struct rtc_device *rtc = platform_get_drvdata(plat_dev);
retval = count;
- if (strncmp(buf, "tick", 4) == 0)
+ if (strncmp(buf, "tick", 4) == 0 && rtc->pie_enabled)
rtc_update_irq(rtc, 1, RTC_PF | RTC_IRQF);
- else if (strncmp(buf, "alarm", 5) == 0)
- rtc_update_irq(rtc, 1, RTC_AF | RTC_IRQF);
- else if (strncmp(buf, "update", 6) == 0)
+ else if (strncmp(buf, "alarm", 5) == 0) {
+ struct rtc_wkalrm alrm;
+ int err = rtc_read_alarm(rtc, &alrm);
+
+ if (!err && alrm.enabled)
+ rtc_update_irq(rtc, 1, RTC_AF | RTC_IRQF);
+
+ } else if (strncmp(buf, "update", 6) == 0 && rtc->uie_rtctimer.enabled)
rtc_update_irq(rtc, 1, RTC_UF | RTC_IRQF);
else
retval = -EINVAL;
The rtc-test driver is meant to provide a test/debug code for the RTC subsystem. The rtc-test driver simulates specific interrupts by echoing to the sys interface. Those were the update, alarm and periodic interrupts. As a side effect of the new implementation, any interrupt generated in the rtc-test driver would trigger the same code path in the generic code, and thus the distinction among interrupts gets lost. This patch preserves the previous behaviour of the rtc-test driver, where e.g. an update interrupt would not trigger an alarm or periodic interrupt, and vice-versa. In real world RTC drivers, this is not an issue, but in the rtc-test driver it may be interesting to distinguish these interrupts for testing purposes. Signed-off-by: Marcelo Roberto Jimenez <mroberto@cpti.cetuc.puc-rio.br> --- drivers/rtc/rtc-test.c | 13 +++++++++---- 1 files changed, 9 insertions(+), 4 deletions(-)