[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3958728.Cz3JcLN4Uc@wuerfel>
Date: Fri, 28 Nov 2014 00:23:48 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Xunlei Pang <pang.xunlei@...aro.org>, linux-kernel@...r.kernel.org,
rtc-linux@...glegroups.com,
Alessandro Zummo <a.zummo@...ertech.it>,
Sven Schnelle <svens@...ckframe.org>,
John Stultz <john.stultz@...aro.org>,
Arnd Bergmann <arnd.bergmann@...aro.org>
Subject: Re: [RFC PATCH 2/4] rtc: Convert rtc_class_ops.set_mmss() to use time64_t
On Friday 28 November 2014 00:05:34 Thomas Gleixner wrote:
> On Thu, 27 Nov 2014, Xunlei Pang wrote:
> > -static int coh901331_set_mmss(struct device *dev, unsigned long secs)
> > +static int coh901331_set_mmss(struct device *dev, time64_t secs)
> > {
> > struct coh901331_port *rtap = dev_get_drvdata(dev);
> >
> > clk_enable(rtap->clk);
> > + /*
> > + * y2106 issue:
> > + * On 32bit systems the time64_t secs value gets cast to
> > + * a 32bit long, and thus we can only write a maximum value
> > + * of y2016
>
> That really makes a lot of sense. Before that patch the driver was
> safe up to 2038. Now it is facing the y2016 problem.
Actually the comment is still wrong with the number fixed, I hadn't
noticed when I looked at the patch earlier:
The cast happens on both 32-bit and 64-bit, as we cast into a u32
value through the writel(). The behavior of this driver doesn't
even change with this patch, it was good until y2106 and stays
that way because 'unsigned long', 'time64_t' and 'u32' can all represent
at least times between 1970 and 2106, the change is just to document
the time at which it will break, while changing the API.
Some other drivers in this patch actually get changed to work beyond
2106, to the full time span that their hardware register layout allows.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists