On 20/06/2017 at 22:15:36 +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 20, 2017 at 05:07:46PM +0200, Benjamin Gaignard wrote:
> > 2017-06-20 15:48 GMT+02:00 Alexandre Belloni
> > <alexandre.belloni(a)free-electrons.com>:
> > >> Yes, that's argument against changing rtc _drivers_ for hardware that
> > >> can not do better than 32bit. For generic code (such as 44/51 sysfs,
> > >> 51/51 suspend test), the change still makes sense.
> >
> > What I had in mind when writing those patches was to remove the limitations
> > coming from those functions usage, even more since they been marked has
> > deprecated.
>
> I'd say that they should not be marked as deprecated. They're entirely
> appropriate for use with hardware that only supports a 32-bit
> representation of time.
>
> It's entirely reasonable to fix the ones that use other representations
> that exceed that, but for those which do not, we need to keep using the
> 32-bit versions. Doing so actually gives us _more_ flexibility in the
> future.
>
> Consider that at the moment, we define the 32-bit RTC representation to
> start at a well known epoch. We _could_ decide that when it wraps to
> 0x80000000 seconds, we'll define the lower 0x40000000 seconds to mean
> dates in the future - and keep rolling that forward each time we cross
> another 0x40000000 seconds. Unless someone invents a real time machine,
> we shouldn't need to set a modern RTC back to 1970.
>
I agree with that but not the android guys. They seem to mandate an RTC
that can store time from 01/01/1970. I don't know much more than that
because they never cared to explain why that was actually necessary
(apart from a laconic "this will result in a bad user experience")
I think tglx had a plan for offsetting the time at some point so 32-bit
platform can pass 2038 properly.
My opinion is that as long as userspace is not ready to handle those
dates, it doesn't really matter because it is quite unlikely that
anything will be able to continue running anyway.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
On 32bits platforms "struct timeval" or "time_t" are using u32 to code the
date, this cause tools like "date" or "hwclock" failed even before setting
the RTC device if the date is superior to year 2038 (or 2106).
To avoid this problem I add two RTC tests files which directly use RTC ioctl
to set and read RTC time and alarm values.
rtctest_setdate allow to set any date/time given in the command line.
rtctest-2038 perform a basic test by writing 1-1-2200 in RTC time and alarm
and checking that the read back values are correct.
Finally that had allowed me to test and fix rtc-st-lpc driver.
Benjamin Gaignard (3):
tools: timer: add rtctest_setdate
tools: timer: add test to check y2038/2106 bug
rtc: st-lpc: make it robust against y2038/2106 bug
drivers/rtc/rtc-st-lpc.c | 19 ++--
tools/testing/selftests/timers/Makefile | 4 +-
tools/testing/selftests/timers/rtctest-2038.c | 135 +++++++++++++++++++++++
tools/testing/selftests/timers/rtctest_setdate.c | 86 +++++++++++++++
4 files changed, 232 insertions(+), 12 deletions(-)
create mode 100644 tools/testing/selftests/timers/rtctest-2038.c
create mode 100644 tools/testing/selftests/timers/rtctest_setdate.c
--
1.9.1