Hello Alexandre,
Cc += Arnd
On Tue, Dec 01, 2015 at 03:42:18PM +0100, Alexandre Belloni wrote:
> > +/**
> > + * rx6110_set_time - set the current time in the rx6110 registers
> > + *
> > + * @dev: the rtc device in use
> > + * @tm: holds date and time
> > + *
> > + * BUG: The HW assumes every year that is a multiple of 4 to be a leap
> > + * year. Next time this is wrong is 2100, which will not be a leap year
> > + *
> > + * Note: If STOP is not set/cleared, the clock will start when the seconds
> > + * register is written
> > + *
> > + */
> > +static int rx6110_set_time(struct device *dev, struct rtc_time *tm)
> > +{
> > + struct rx6110_data *rx6110 = dev_get_drvdata(dev);
> > + int ret;
> > +
> > + if (tm->tm_year > 137)
> > + return -EINVAL;
> > +
>
> Seeing the comment comment above, this should probably be if
> (tm->tm_year < 100 || tm->tm_year >= 200)
> I don't think this particular part has any issue
> handling 2038. However, on 32bit platform, your userspace is probably
> not ready to handle those date. hwclock should return the correct date.
userspace is not ready because it cannot. Before this can be addressed,
quite some things need fixing first. If I understood correctly timerfd
for example is broken which completely locks up systemd.
Note this doesn't justify to not write a date later than 2037 in the rtc
driver however. Still thinking about how to handle this for the machines
we work on, we thought about letting the RTC_RD_TIME ioctl fail for
dates later than 2038 to work around this issue.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
