Messages in this thread | | | Date | Fri, 28 Nov 2014 00:28:16 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [RFC PATCH 2/4] rtc: Convert rtc_class_ops.set_mmss() to use time64_t |
| |
On Fri, 28 Nov 2014, Arnd Bergmann wrote: > 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.
Indeed. I did not bother to think about that as I was already in grumpy mode due to the general aproach of creating the maximal churn for no value.
Thanks,
tglx
| |