Received: by 10.223.185.116 with SMTP id b49csp4454794wrg; Mon, 26 Feb 2018 18:49:18 -0800 (PST) X-Google-Smtp-Source: AH8x224ruhp28rYjljltfFP/w4t5c2u910tdh4jDGKmXp+jwN7ZWrQ7/Sah+dcQ4i7rfFhKo/y+y X-Received: by 2002:a17:902:6805:: with SMTP id h5-v6mr12645033plk.46.1519699758462; Mon, 26 Feb 2018 18:49:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519699758; cv=none; d=google.com; s=arc-20160816; b=yh9XguZLKL8JFiJVPG/yI1n4pv8EFxu/34++R8W0PV+azDIwSDjTs8ZnFsW3uA/AWp dQFhT772vD9TqM4rG49JwELl85pGzts1ZwDQeRz21qN2goqJW222F/Qg/WoCdMHl1rrT rlEd3hrJaOAt16pHzvyes8hIp6YYlEedfX2nYhHaLws2DbVcRAw8ldLBtZDpNLhSNZHP 35FaL4lTUVJlP6pQh11wy31GkKycs9KXrA6rWgZBvujnPMpXvS+piOlOmINHtKkfdb8g VOhQvWuKiZeybYZuss+qnkS5XK22NhJKxAMQF86lDu8AEbQNMicJ1OkX3N6+3dpSHmSs vALg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=VRc9IW4vV/ggYeB0QTD3h5PN460vYaNh4QuD23J2Gc4=; b=dfggrN6kEIciIG1qMoEvhq7UHHl1j3Gw9+p5cDE5rjvVkwJnczs3qNT7VI+fGrlS3S w+/Rl63ottUGGzZNjFVhKpLHmPx7O1FZjK+qHmFny1lj+TZoex7z7TDUp9xDqSt1Lv5J l2eaRFwEdSFeJO+nTibTLYaNhxjjtWljvLiWRgSaFLwCb6w9FJQjnuOgLG9gqLhc5PWB mOjPVMtmT7etGPA6y8RBqMdqZ9mVOvrH6c65YUAUaYIgDfznnOkV+l6IPfTsrD5/ML15 IymXZw8KiADCRP9ZPbueiQfpBq9Ipnx+oi4bYmPIIr8V/qWxPe+rXMRC56GR5p57K254 JXhA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o1-v6si7699231plb.280.2018.02.26.18.49.03; Mon, 26 Feb 2018 18:49:18 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751723AbeB0Cro (ORCPT + 99 others); Mon, 26 Feb 2018 21:47:44 -0500 Received: from regular1.263xmail.com ([211.150.99.136]:52162 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751505AbeB0Crm (ORCPT ); Mon, 26 Feb 2018 21:47:42 -0500 Received: from jeffy.chen?rock-chips.com (unknown [192.168.167.8]) by regular1.263xmail.com (Postfix) with ESMTP id 58E5989; Tue, 27 Feb 2018 10:47:40 +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 89F3F3B0; Tue, 27 Feb 2018 10:47:36 +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: <5322603469e8fb4bdd4eb76ff1f413f7> 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 32022768VID; Tue, 27 Feb 2018 10:47:39 +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 v3] rtc: cros-ec: return -ETIME when refused to set alarms in the past Date: Tue, 27 Feb 2018 10:47:34 +0800 Message-Id: <20180227024734.7591-1-jeffy.chen@rock-chips.com> X-Mailer: git-send-email 2.11.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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 v3: Fix alarm time comparing. Changes in v2: Rewrite commit message as Brian suggested. Check alarm time only when that alarm is enabled. drivers/rtc/rtc-cros-ec.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/rtc/rtc-cros-ec.c b/drivers/rtc/rtc-cros-ec.c index f0ea6899c731..510a4ced2edf 100644 --- a/drivers/rtc/rtc-cros-ec.c +++ b/drivers/rtc/rtc-cros-ec.c @@ -198,9 +198,9 @@ static int cros_ec_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm) } else { /* 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; + return -ETIME; + + alarm_offset = (u32)alarm_time - current_time; } ret = cros_ec_rtc_set(cros_ec, EC_CMD_RTC_SET_ALARM, alarm_offset); -- 2.11.0