From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754571AbcHaXl2 (ORCPT ); Wed, 31 Aug 2016 19:41:28 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:36141 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753356AbcHaXl0 (ORCPT ); Wed, 31 Aug 2016 19:41:26 -0400 Subject: Re: [PATCH] rtc-cmos: Reject unsupported alarm values To: a.zummo@towertech.it, alexandre.belloni@free-electrons.com References: <20160831225929.20336-1-gabriele.mzt@gmail.com> Cc: rtc-linux@googlegroups.com, linux-kernel@vger.kernel.org From: Gabriele Mazzotta Message-ID: <51495377-fcf7-df2c-bac4-ef32334158a3@gmail.com> Date: Thu, 1 Sep 2016 01:41:18 +0200 MIME-Version: 1.0 In-Reply-To: <20160831225929.20336-1-gabriele.mzt@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/09/2016 00:59, Gabriele Mazzotta wrote: > Return an error if the user tries to set an alarm that isn't > supported by the hardware. > > Signed-off-by: Gabriele Mazzotta > --- > drivers/rtc/rtc-cmos.c | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c > index 4cdb335..b3f9298 100644 > --- a/drivers/rtc/rtc-cmos.c > +++ b/drivers/rtc/rtc-cmos.c > @@ -336,6 +336,26 @@ static int cmos_set_alarm(struct device *dev, struct rtc_wkalrm *t) > if (!is_valid_irq(cmos->irq)) > return -EIO; > > + if (!cmos->mon_alrm || !cmos->day_alrm) { > + struct rtc_time now; > + time64_t t_now; > + time64_t t_alrm; > + > + cmos_read_time(dev, &now); > + t_now = rtc_tm_to_time64(&now); > + t_alrm = rtc_tm_to_time64(&t->time); > + if (!cmos->day_alrm && (t_alrm - t_now) > (24 * 60 * 60)) { > + dev_err(dev, > + "Alarms can be up to one day in the future\n"); > + return -EINVAL; > + } > + if (!cmos->mon_alrm && (t_alrm - t_now) > (31 * 24 * 60 * 60)) { I actually realized this is wrong. It's possible for this to let some invalid dates go through. The driver writes a date in the registers, so if mon_alrm is missing, I need to do something better than adding 31 days. Sorry, I was thinking about time deltas rather than well defined dates. > + dev_err(dev, > + "Alarms can be up to 31 days in the future\n"); > + return -EINVAL; > + } > + } > + > mon = t->time.tm_mon + 1; > mday = t->time.tm_mday; > hrs = t->time.tm_hour; >