From patchwork Mon Jan 8 06:04:50 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "\(Exiting\) Baolin Wang" X-Patchwork-Id: 123685 Delivered-To: patch@linaro.org Received: by 10.140.22.227 with SMTP id 90csp2333851qgn; Sun, 7 Jan 2018 22:05:34 -0800 (PST) X-Google-Smtp-Source: ACJfBot3wgPMwj2MdkVrIQJGmgx711haaWqsFv4WelM0yJeeKaTjakqPi+kMXt2N6MmU+fHUivS4 X-Received: by 10.84.128.36 with SMTP id 33mr10685297pla.75.1515391534432; Sun, 07 Jan 2018 22:05:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1515391534; cv=none; d=google.com; s=arc-20160816; b=JZ+IJQ0zxVVvX2HyB4bq14/jXgFHIPPUqqs8HLqE+tqhzSmPYViP8o21wLbS9GqCf8 KpJ5XROQJBaV3Fb2o/EdpbQ1VwVwVe8hU424bGjaZG0mdXmIogHwkzHWxajmgjKJuURg W18V7Qk23c3Ua2iYJ4h0pbWFOc6Qn9yrBe+cVGAvM6VwuuxpKKNSNsmWxh4UGeZ5dpn6 0sWOPiYb5tDWNxOk0frNR7vIbtS0pWJ8twBk9sL3VR25ezahXfDhKL4gkJVqyVhTNYrB aR7wEb86WwilffJIpYqw05Nb8cnJfYcoPzSvveeumqjLqhcGlZ2K7gewcFFd9NqlFycO gCmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:dkim-signature :arc-authentication-results; bh=Rzt+TIFX9pPZxeywMbYfeGddl4aUz4+E140pSFDJjbA=; b=nfLdlzoeF6+qRNrreSApfVbL2BtUKKGLiTGJRcThM9daEGjLyU8LqJ8CBIgc0Nd3xa /MOP3iiqVgOehQMGuD1zYS4vWeRKK5+iYRjVJKgLPCU9PW4XyLb68qQ9kFwx4dvJDitc Vh4GNkf9X6OGt1FbA7bIFzBY6QBQ/KWR6eqe1onzLqGK88IhCHhPQVe3WBgk8/isJlvR GvtbhwznePepILnqN6vAX/5NVRY/ru8GEBensSFqvn4jvBZlxgg1xdpbnG1Mm1KEX0p7 XTwyVZugDYIvikJGkwjPaysV60HlNasD+aKKJVUfSq1JM0pgtaqGdCVV8p3zW4ImjkE4 jaFQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=cEawMtlJ; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g185si4498466pgc.121.2018.01.07.22.05.34; Sun, 07 Jan 2018 22:05:34 -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; dkim=pass header.i=@linaro.org header.s=google header.b=cEawMtlJ; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755618AbeAHGFa (ORCPT + 28 others); Mon, 8 Jan 2018 01:05:30 -0500 Received: from mail-pf0-f193.google.com ([209.85.192.193]:46569 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755541AbeAHGF0 (ORCPT ); Mon, 8 Jan 2018 01:05:26 -0500 Received: by mail-pf0-f193.google.com with SMTP id y5so1397521pff.13 for ; Sun, 07 Jan 2018 22:05:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :in-reply-to:references; bh=Rzt+TIFX9pPZxeywMbYfeGddl4aUz4+E140pSFDJjbA=; b=cEawMtlJj5YcKcyCmZ0LcQk0da05HwyiJ7GZkaAVY56EgsdJmAgYYfQQMtFybTiya4 rH55LvhZbqNz5/0IF8fjku8IwuUJxv+ss8014oBzaVbC/ZOgFmK8qD3ybr+6CE/uAFef cl/hWsIUzxrToHdE1EQ+zat4RS3q95XBwrqzs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:in-reply-to:references; bh=Rzt+TIFX9pPZxeywMbYfeGddl4aUz4+E140pSFDJjbA=; b=aFtXWycvoPCZuKBW8eZ0FVO0YJ2GsRDC0Nwxp2U6X1oC41yeg0fWQxdX6FWuZAuSA0 Rco83anruS6dMgx/l8eCaamJLhgpz930bypcmjymSxa1eh2MwehmQh3yJQKASkrfQ3sZ ZeL1Ot0tJCPdAiwClnQrSSIbfuuHraZCaVG+j+7jmadBqKSwzTeZf5pizDnQh+ky+am0 knq3R646Z2L/75YiWATwZ+bQgjvXwFYGvudqbgJjdSkwLl3CHL/9KcvMUYy12Dm4Up8I zKKs7HUfPtgxX8lkii955tbPoe1F2Knhnz7hdOLk09DQwTK34RzWIgoXaF/Nyxu4P3hR K3nw== X-Gm-Message-State: AKGB3mKQD4eVAuNDvINAuUPst1dvEJh7arTeovFIcy5/RwsIQG8wa8jL giLFmOtuGaEXTJ6wiC3kkuTo5g== X-Received: by 10.99.97.137 with SMTP id v131mr4259317pgb.243.1515391525472; Sun, 07 Jan 2018 22:05:25 -0800 (PST) Received: from baolinwangubtpc.spreadtrum.com ([117.18.48.82]) by smtp.gmail.com with ESMTPSA id q5sm20468615pgn.39.2018.01.07.22.05.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 07 Jan 2018 22:05:25 -0800 (PST) From: Baolin Wang To: a.zummo@towertech.it, alexandre.belloni@free-electrons.com Cc: arnd@arndb.de, broonie@kernel.org, linux-rtc@vger.kernel.org, linux-kernel@vger.kernel.org, baolin.wang@linaro.org Subject: [PATCH 3/3] rtc: Add one offset seconds to expand RTC range Date: Mon, 8 Jan 2018 14:04:50 +0800 Message-Id: <06dbb64a54a0f540805fe21bd791a9ae40577041.1515390560.git.baolin.wang@linaro.org> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: References: In-Reply-To: References: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >From our investigation for all RTC drivers, 1 driver will be expired before year 2017, 7 drivers will be expired before year 2038, 23 drivers will be expired before year 2069, 72 drivers will be expired before 2100 and 104 drivers will be expired before 2106. Especially for these early expired drivers, we need to expand the RTC range to make the RTC can still work after the expired year. So we can expand the RTC range by adding one offset to the time when reading from hardware, and subtracting it when writing back. For example, if you have an RTC that can do 100 years, and currently is configured to be based in Jan 1 1970, so it can represents times from 1970 to 2069. Then if you change the start year from 1970 to 2000, which means it can represents times from 2000 to 2099. By adding or subtracting the offset produced by moving the wrap point, all times between 1970 and 1999 from RTC hardware could get interpreted as times from 2070 to 2099, but the interpretation of dates between 2000 and 2069 would not change. Signed-off-by: Baolin Wang --- drivers/rtc/class.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++ drivers/rtc/interface.c | 59 ++++++++++++++++++++++++++++++++++++++- include/linux/rtc.h | 3 ++ 3 files changed, 131 insertions(+), 1 deletion(-) -- 1.7.9.5 diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c index 722d683..086a42b 100644 --- a/drivers/rtc/class.c +++ b/drivers/rtc/class.c @@ -211,6 +211,73 @@ static int rtc_device_get_id(struct device *dev) return id; } +static void rtc_device_get_offset(struct rtc_device *rtc) +{ + time64_t range_secs; + u32 start_year; + int ret; + + /* + * If RTC driver did not implement the range of RTC hardware device, + * then we can not expand the RTC range by adding or subtracting one + * offset. + */ + if (rtc->range_min == rtc->range_max) + return; + + ret = device_property_read_u32(rtc->dev.parent, "start-year", + &start_year); + if (!ret) { + rtc->start_secs = mktime64(start_year, 1, 1, 0, 0, 0); + rtc->set_start_time = true; + } + + /* + * If user did not implement the start time for RTC driver, then no + * need to expand the RTC range. + */ + if (!rtc->set_start_time) + return; + + range_secs = rtc->range_max - rtc->range_min + 1; + + /* + * If the start_secs is larger than the maximum seconds (rtc->range_max) + * supported by RTC hardware or the maximum seconds of new expanded + * range (start_secs + rtc->range_max - rtc->range_min) is less than + * rtc->range_min, which means the minimum seconds (rtc->range_min) of + * RTC hardware will be mapped to start_secs by adding one offset, so + * the offset seconds calculation formula should be: + * rtc->offset_secs = rtc->start_secs - rtc->range_min; + * + * If the start_secs is larger than the minimum seconds (rtc->range_min) + * supported by RTC hardware, then there is one region is overlapped + * between the original RTC hardware range and the new expanded range, + * and this overlapped region do not need to be mapped into the new + * expanded range due to it is valid for RTC device. So the minimum + * seconds of RTC hardware (rtc->range_min) should be mapped to + * rtc->range_max + 1, then the offset seconds formula should be: + * rtc->offset_secs = rtc->range_max - rtc->range_min + 1; + * + * If the start_secs is less than the minimum seconds (rtc->range_min), + * which is similar to case 2. So the start_secs should be mapped to + * start_secs + rtc->range_max - rtc->range_min + 1, then the + * offset seconds formula should be: + * rtc->offset_secs = -(rtc->range_max - rtc->range_min + 1); + * + * Otherwise the offset seconds should be 0. + */ + if (rtc->start_secs > rtc->range_max || + rtc->start_secs + range_secs - 1 < rtc->range_min) + rtc->offset_secs = rtc->start_secs - rtc->range_min; + else if (rtc->start_secs > rtc->range_min) + rtc->offset_secs = range_secs; + else if (rtc->start_secs < rtc->range_min) + rtc->offset_secs = -range_secs; + else + rtc->offset_secs = 0; +} + /** * rtc_device_register - register w/ RTC class * @dev: the device to register @@ -247,6 +314,8 @@ struct rtc_device *rtc_device_register(const char *name, struct device *dev, dev_set_name(&rtc->dev, "rtc%d", id); + rtc_device_get_offset(rtc); + /* Check to see if there is an ALARM already set in hw */ err = __rtc_read_alarm(rtc, &alrm); @@ -435,6 +504,7 @@ int __rtc_register_device(struct module *owner, struct rtc_device *rtc) return -EINVAL; rtc->owner = owner; + rtc_device_get_offset(rtc); /* Check to see if there is an ALARM already set in hw */ err = __rtc_read_alarm(rtc, &alrm); diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c index 55ada51..ce47e47 100644 --- a/drivers/rtc/interface.c +++ b/drivers/rtc/interface.c @@ -20,12 +20,61 @@ static int rtc_timer_enqueue(struct rtc_device *rtc, struct rtc_timer *timer); static void rtc_timer_remove(struct rtc_device *rtc, struct rtc_timer *timer); +static void rtc_add_offset(struct rtc_device *rtc, struct rtc_time *tm) +{ + time64_t secs; + + if (!rtc->offset_secs) + return; + + secs = rtc_tm_to_time64(tm); + + /* + * Since the reading time values from RTC device are always in the RTC + * original valid range, but we need to skip the overlapped region + * between expanded range and original range, which is no need to add + * the offset. + */ + if ((rtc->start_secs > rtc->range_min && secs >= rtc->start_secs) || + (rtc->start_secs < rtc->range_min && + secs <= (rtc->start_secs + rtc->range_max - rtc->range_min))) + return; + + rtc_time64_to_tm(secs + rtc->offset_secs, tm); +} + +static void rtc_subtract_offset(struct rtc_device *rtc, struct rtc_time *tm) +{ + time64_t secs; + + if (!rtc->offset_secs) + return; + + secs = rtc_tm_to_time64(tm); + + /* + * If the setting time values are in the valid range of RTC hardware + * device, then no need to subtract the offset when setting time to RTC + * device. Otherwise we need to subtract the offset to make the time + * values are valid for RTC hardware device. + */ + if (secs >= rtc->range_min && secs <= rtc->range_max) + return; + + rtc_time64_to_tm(secs - rtc->offset_secs, tm); +} + static int rtc_valid_range(struct rtc_device *rtc, struct rtc_time *tm) { if (rtc->range_min != rtc->range_max) { time64_t time = rtc_tm_to_time64(tm); + time64_t range_min = rtc->set_start_time ? rtc->start_secs : + rtc->range_min; + time64_t range_max = rtc->set_start_time ? + (rtc->start_secs + rtc->range_max - rtc->range_min) : + rtc->range_max; - if (time < rtc->range_min || time > rtc->range_max) + if (time < range_min || time > range_max) return -ERANGE; } @@ -48,6 +97,8 @@ static int __rtc_read_time(struct rtc_device *rtc, struct rtc_time *tm) return err; } + rtc_add_offset(rtc, tm); + err = rtc_valid_tm(tm); if (err < 0) dev_dbg(&rtc->dev, "read_time: rtc_time isn't valid\n"); @@ -81,6 +132,8 @@ int rtc_set_time(struct rtc_device *rtc, struct rtc_time *tm) if (err) return err; + rtc_subtract_offset(rtc, tm); + err = mutex_lock_interruptible(&rtc->ops_lock); if (err) return err; @@ -135,6 +188,8 @@ static int rtc_read_alarm_internal(struct rtc_device *rtc, struct rtc_wkalrm *al } mutex_unlock(&rtc->ops_lock); + + rtc_add_offset(rtc, &alarm->time); return err; } @@ -345,6 +400,8 @@ static int __rtc_set_alarm(struct rtc_device *rtc, struct rtc_wkalrm *alarm) err = rtc_valid_tm(&alarm->time); if (err) return err; + + rtc_subtract_offset(rtc, &alarm->time); scheduled = rtc_tm_to_time64(&alarm->time); /* Make sure we're not setting alarms in the past */ diff --git a/include/linux/rtc.h b/include/linux/rtc.h index 4ac60af..c062eeb 100644 --- a/include/linux/rtc.h +++ b/include/linux/rtc.h @@ -154,6 +154,9 @@ struct rtc_device { time64_t range_min; time64_t range_max; + time64_t start_secs; + time64_t offset_secs; + bool set_start_time; #ifdef CONFIG_RTC_INTF_DEV_UIE_EMUL struct work_struct uie_task;