rtc: sandbox-rtc: fix set method
authorRasmus Villemoes <rasmus.villemoes@prevas.dk>
Mon, 6 Jul 2020 20:01:16 +0000 (22:01 +0200)
committerHeiko Schocher <hs@denx.de>
Thu, 9 Jul 2020 04:02:45 +0000 (06:02 +0200)
commit9fb6a41cdaa743c98b007c6769970b68c9521cd7
tree8e688b7f4aaa235b3fa304c2355e9367db5fb672
parent803a859884b73dbc10826ed26fbf62d487ddc5c7
rtc: sandbox-rtc: fix set method

The current set method is broken; a simple test case is to first set
the date to something in April, then change the date to 31st May:

=> date 040412122020.34
Date: 2020-04-04 (Saturday)    Time: 12:12:34
=> date 053112122020.34
Date: 2020-05-01 (Friday)    Time: 12:12:34

or via the amending of the existing rtc_set_get test case similarly:

$ ./u-boot -T -v
=> ut dm rtc_set_get
Test: dm_test_rtc_set_get: rtc.c
expected: 31/08/2004 18:18:00
actual: 01/08/2004 18:18:00

The problem is that after each register write,
sandbox_i2c_rtc_complete_write() gets called and sets the internal
time from the current set of registers. However, when we get to
writing 31 to mday, the registers are in an inconsistent state (mon is
still 4), so the mktime machinery ends up translating April 31st to
May 1st. Upon the next register write, the registers are populated by
sandbox_i2c_rtc_prepare_read(), so the 31 we just wrote to mday gets
overwritten by a 1.

Fix it by writing all registers at once, and for consistency, update
the get method to retrieve them all with one "i2c transfer".

Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
drivers/rtc/sandbox_rtc.c
test/dm/rtc.c