From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Sun, 31 May 2020 08:07:49 -0600 Subject: [PATCH v2 07/10] rtc: sandbox-rtc: fix set method In-Reply-To: <20200519220117.24448-8-rasmus.villemoes@prevas.dk> References: <20200504212032.3759-1-rasmus.villemoes@prevas.dk> <20200519220117.24448-1-rasmus.villemoes@prevas.dk> <20200519220117.24448-8-rasmus.villemoes@prevas.dk> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, 19 May 2020 at 16:01, Rasmus Villemoes wrote: > > 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". > > Signed-off-by: Rasmus Villemoes > --- > drivers/rtc/sandbox_rtc.c | 65 +++++++++++++++------------------------ > test/dm/rtc.c | 15 ++++++++- > 2 files changed, 38 insertions(+), 42 deletions(-) Nice fix! Reviewed-by: Simon Glass