Re: [PATCH v3 5/7] rtc: New driver for RTC in Netronix embedded controller

[Jonathan Neuschäfer]

On Sun, Oct 04, 2020 at 10:42:09AM +0200, Alexandre Belloni wrote:
> On 04/10/2020 03:43:23+0200, Jonathan Neuschäfer wrote:
> > > > +static int ntxec_set_time(struct device *dev, struct rtc_time *tm)
....
> > > > +	res = regmap_write(rtc->ec->regmap, NTXEC_REG_WRITE_MINUTE, ntxec_reg8(tm->tm_min));
> > > > +	if (res)
> > > > +		return res;
> > > > +
> > > > +	return regmap_write(rtc->ec->regmap, NTXEC_REG_WRITE_SECOND, ntxec_reg8(tm->tm_sec));
> > > 
> > > I wonder: Is this racy? If you write minute, does the seconds reset to
> > > zero or something like that? Or can it happen, that after writing the
> > > minute register and before writing the second register the seconds
> > > overflow and you end up with the time set to a minute later than
> > > intended? If so it might be worth to set the seconds to 0 at the start
> > > of the function (with an explaining comment).
> > 
> > The setting the minutes does not reset the seconds, so I think this race
> > condition is possible. I'll add the workaround.
> > 
> 
> Are you sure this happens? Usually, the seconds are not reset but the
> internal 32768kHz counter is so you have a full second to write all the
> registers.

I just checked it, and on this RTC, the phase / sub-second part is not
reset when the time is set.

> > > .read_time has a similar race. What happens if minutes overflow between
> > > reading NTXEC_REG_READ_DH and NTXEC_REG_READ_MS?
> > 
> > Yes, we get read tearing in that case. It could even propagate all the
> > way to the year/month field, for example when the following time rolls
> > over:
> > 	   A   |  B  |  C
> > 	2020-10-31 23:59:59
> > 	2020-11-01 00:00:00
> > 
> > - If the increment happens after reading C, we get         2020-10-31 23:59:59
> > - If the increment happens between reading B and C, we get 2020-10-31 23:00:00
> > - If the increment happens between reading A and B, we get 2020-10-01 00:00:00
> > - If the increment happens before reading A, we get        2020-11-01 00:00:00
> > 
> > ... both of which are far from correct.
> > 
> > To mitigate this issue, I think something like the following is needed:
> > 
> > - Read year/month
> > - Read day/hour
> > - Read minute/second
> > - Read day/hour, compare with previously read value, restart on mismatch
> > - Read year/month, compare with previously read value, restart on mismatch
> > 
> > The order of the last two steps doesn't matter, as far as I can see, but
> > if I remove one of them, I can't catch all cases of read tearing.
> > 
> 
> Are you also sure this happens?
> 
> Only one comparison is necessary, the correct order would be:
> 
>  - Read minute/second
>  - Read day/hour
>  - Read year/month
>  - Read minute/second, compare

With this order, every one-second increment is detected, which I
previously tried to avoid. But I suppose it's fine because it simplifies
the logic and the window from first to last read should be short enough
anyway to be relatively unlikely to hit, and thus not cause a lot of retries.

> If day/hour changes but not minute/second, it would mean that it took at
> least an hour to read all the registers. At this point, I think you have
> other problems and the exact time doesn't matter anymore.

Indeed.


Thanks,
Jonathan Neuschäfer

Attachment: signature.asc
Description: PGP signature