From patchwork Tue Feb 27 02:43:57 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeffy Chen X-Patchwork-Id: 878303 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-rtc-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=rock-chips.com Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3zr31W4gg5z9s1c for ; Tue, 27 Feb 2018 13:44:15 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751553AbeB0CoN (ORCPT ); Mon, 26 Feb 2018 21:44:13 -0500 Received: from regular1.263xmail.com ([211.150.99.139]:34555 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751463AbeB0CoN (ORCPT ); Mon, 26 Feb 2018 21:44:13 -0500 Received: from jeffy.chen?rock-chips.com (unknown [192.168.167.243]) by regular1.263xmail.com (Postfix) with ESMTP id 52623548A; Tue, 27 Feb 2018 10:44:10 +0800 (CST) X-263anti-spam: KSV:0; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-KSVirus-check: 0 X-ABS-CHECKED: 4 Received: from localhost (localhost [127.0.0.1]) by smtp.263.net (Postfix) with ESMTPA id 266AD384; Tue, 27 Feb 2018 10:44:00 +0800 (CST) X-RL-SENDER: jeffy.chen@rock-chips.com X-FST-TO: linux-kernel@vger.kernel.org X-SENDER-IP: 103.29.142.67 X-LOGIN-NAME: jeffy.chen@rock-chips.com X-UNIQUE-TAG: X-ATTACHMENT-NUM: 0 X-SENDER: cjf@rock-chips.com X-DNS-TYPE: 0 Received: from localhost (unknown [103.29.142.67]) by smtp.263.net (Postfix) whith ESMTP id 32252NM9JJV; Tue, 27 Feb 2018 10:44:06 +0800 (CST) From: Jeffy Chen To: linux-kernel@vger.kernel.org Cc: zyw@rock-chips.com, briannorris@google.com, dianders@google.com, jwerner@chromium.org, Jeffy Chen , linux-rtc@vger.kernel.org, Alexandre Belloni , Alessandro Zummo Subject: [PATCH v2] rtc: cros-ec: return -ETIME when refused to set alarms in the past Date: Tue, 27 Feb 2018 10:43:57 +0800 Message-Id: <20180227024357.4897-1-jeffy.chen@rock-chips.com> X-Mailer: git-send-email 2.11.0 Sender: linux-rtc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rtc@vger.kernel.org Since accessing a Chrome OS EC based rtc is a slow operation, there is a race window where if the alarm is set for the next second and the second ticks over right before calculating the alarm offset. In this case the current driver is setting a 0-second alarm, which would be considered as disabling alarms by the EC(EC_RTC_ALARM_CLEAR). This breaks, e.g., hwclock which relies on RTC_UIE_ON -> rtc_update_irq_enable(), which sets a 1-second alarm and expects it to fire an interrupt. So return -ETIME when the alarm is in the past, follow __rtc_set_alarm(). Signed-off-by: Jeffy Chen --- Changes in v2: Rewrite commit message as Brian suggested. Check alarm time only when that alarm is enabled. drivers/rtc/rtc-cros-ec.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/rtc/rtc-cros-ec.c b/drivers/rtc/rtc-cros-ec.c index f0ea6899c731..ae7e8554679f 100644 --- a/drivers/rtc/rtc-cros-ec.c +++ b/drivers/rtc/rtc-cros-ec.c @@ -196,11 +196,11 @@ static int cros_ec_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm) alarm_offset = EC_RTC_ALARM_CLEAR; cros_ec_rtc->saved_alarm = (u32)alarm_time; } else { + alarm_offset = (u32)alarm_time - current_time; + /* Don't set an alarm in the past. */ - if ((u32)alarm_time < current_time) - alarm_offset = EC_RTC_ALARM_CLEAR; - else - alarm_offset = (u32)alarm_time - current_time; + if (alarm_offset <= 0) + return -ETIME; } ret = cros_ec_rtc_set(cros_ec, EC_CMD_RTC_SET_ALARM, alarm_offset);