Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sun, 11 Oct 2020 21:09:10 +0200
From:   Jonathan =?utf-8?Q?Neusch=C3=A4fer?= <j.neuschaefer@gmx.net>
To:     Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc:     Jonathan =?utf-8?Q?Neusch=C3=A4fer?= <j.neuschaefer@gmx.net>,
        Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= 
        <u.kleine-koenig@pengutronix.de>, linux-kernel@vger.kernel.org,
        Heiko Stuebner <heiko@sntech.de>, linux-pwm@vger.kernel.org,
        Linus Walleij <linus.walleij@linaro.org>,
        Thierry Reding <thierry.reding@gmail.com>,
        Fabio Estevam <festevam@gmail.com>, linux-rtc@vger.kernel.org,
        Arnd Bergmann <arnd@arndb.de>,
        Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
        Sam Ravnborg <sam@ravnborg.org>,
        Daniel Palmer <daniel@0x0f.com>,
        Andy Shevchenko <andy.shevchenko@gmail.com>,
        Andreas Kemnade <andreas@kemnade.info>,
        NXP Linux Team <linux-imx@nxp.com>,
        devicetree@vger.kernel.org, Stephan Gerhold <stephan@gerhold.net>,
        allen <allen.chen@ite.com.tw>,
        Sascha Hauer <s.hauer@pengutronix.de>,
        Lubomir Rintel <lkundrak@v3.sk>,
        Rob Herring <robh+dt@kernel.org>,
        Lee Jones <lee.jones@linaro.org>,
        linux-arm-kernel@lists.infradead.org,
        Alessandro Zummo <a.zummo@towertech.it>,
        Mark Brown <broonie@kernel.org>,
        Pengutronix Kernel Team <kernel@pengutronix.de>,
        Heiko Stuebner <heiko.stuebner@theobroma-systems.com>,
        Josua Mayer <josua.mayer@jm0.eu>,
        Shawn Guo <shawnguo@kernel.org>,
        "David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH v3 5/7] rtc: New driver for RTC in Netronix embedded
 controller
Message-ID: <20201011190910.GE500800@latitude>
References: <20200924192455.2484005-1-j.neuschaefer@gmx.net>
 <20200924192455.2484005-6-j.neuschaefer@gmx.net>
 <20200925054424.snlr3lggnsv575wu@pengutronix.de>
 <20201004014323.GD500800@latitude>
 <20201004084209.GV2804081@piout.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="2hMgfIw2X+zgXrFs"
Content-Disposition: inline
In-Reply-To: <20201004084209.GV2804081@piout.net>
Precedence: bulk


--2hMgfIw2X+zgXrFs
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Oct 04, 2020 at 10:42:09AM +0200, Alexandre Belloni wrote:
> On 04/10/2020 03:43:23+0200, Jonathan Neusch=C3=A4fer wrote:
> > > > +static int ntxec_set_time(struct device *dev, struct rtc_time *tm)
=2E...
> > > > +	res =3D regmap_write(rtc->ec->regmap, NTXEC_REG_WRITE_MINUTE, ntx=
ec_reg8(tm->tm_min));
> > > > +	if (res)
> > > > +		return res;
> > > > +
> > > > +	return regmap_write(rtc->ec->regmap, NTXEC_REG_WRITE_SECOND, ntxe=
c_reg8(tm->tm_sec));
> > >=20
> > > 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).
> >=20
> > The setting the minutes does not reset the seconds, so I think this race
> > condition is possible. I'll add the workaround.
> >=20
>=20
> 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 betwe=
en
> > > reading NTXEC_REG_READ_DH and NTXEC_REG_READ_MS?
> >=20
> > 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
> >=20
> > - If the increment happens after reading C, we get         2020-10-31 2=
3:59:59
> > - If the increment happens between reading B and C, we get 2020-10-31 2=
3:00:00
> > - If the increment happens between reading A and B, we get 2020-10-01 0=
0:00:00
> > - If the increment happens before reading A, we get        2020-11-01 0=
0:00:00
> >=20
> > ... both of which are far from correct.
> >=20
> > To mitigate this issue, I think something like the following is needed:
> >=20
> > - 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 misma=
tch
> >=20
> > 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.
> >=20
>=20
> Are you also sure this happens?
>=20
> Only one comparison is necessary, the correct order would be:
>=20
>  - 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 retrie=
s.

> 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=C3=A4fer

--2hMgfIw2X+zgXrFs
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEvHAHGBBjQPVy+qvDCDBEmo7zX9sFAl+DWEYACgkQCDBEmo7z
X9uepA//fs6TCspmRMOe/zMk+MiAPbG25ReDry1BglGSs1eeSHmE96PH7J5nrOId
wQvmP/r+Sf3MqaIie02JZpoj3J223zgb0dfY3fUZ1FwsUpm7lbRJRSmuPEcBcdFd
6VcvgCL9/xASAYe0ShQg2Gni6Gk6zzGLRxx0C+PTDvar9pzutLZKngTAPDM6yDwO
4xlZkGWjQ0jxVhcJnUiNF3ooj/PFbkOLGkHlQfWHToDBXWKDkfDiMGFREdnN6lTI
qzMGwUUCbjEQaGlM/GDMKI+Oq9oqgizZKx+hJ+2hay94cDz/Bh+hqFe5j4TCrvVG
QCnOixWBQs80Zwoei8owdgszzKasJPFTQ08tcnYGsJvdOTHjTPWY1XUPWhZaxdHO
57Pg/t3JpU10VjkEIzdg/qLmdlK7yqZ5BPk1WCeLfobzgr72EKslIveFP+7TmqHG
j9EP5NewELC3Zt5sYvcTy6A7rxNT4TpRr0I3N9As1MNereNq2YV78ylqHDN8xj80
Meo726ga70Tr2nWQ5/VyPabbvsXsuQGjIpcFs3XjfnvpCRDolGUnjEpy3W9EFMqt
WFW5XUa9tw+snOi2VkMxmsVa3nNbpH0dLO22JN+C/Y4yEzpdQBPmLDkQDv4rIDqf
UvXNBVGffn1fxxS3UX71T/KtwxDsGT6+QopIL47DURXw8yqX14Y=
=GuMr
-----END PGP SIGNATURE-----

--2hMgfIw2X+zgXrFs--