Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752640AbdFUHwD (ORCPT ); Wed, 21 Jun 2017 03:52:03 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:57191 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751015AbdFUHwB (ORCPT ); Wed, 21 Jun 2017 03:52:01 -0400 Date: Wed, 21 Jun 2017 09:51:52 +0200 From: Pavel Machek To: Thomas Gleixner Cc: Alexandre Belloni , Russell King - ARM Linux , Benjamin Gaignard , Baruch Siach , "patches@opensource.wolfsonmicro.com" , Linus Walleij , "linux-tegra@vger.kernel.org" , Thierry Reding , "x86@kernel.org" , Jonathan Hunter , Chen-Yu Tsai , Ingo Molnar , Sylvain Lemieux , Sebastian Hesselbarth , Len Brown , "linaro-kernel@lists.linaro.org" , Jason Cooper , "rtc-linux@googlegroups.com" , "linux-pm@vger.kernel.org" , Hans Ulli Kroll , "adi-buildroot-devel@lists.sourceforge.net" , Vladimir Zapolskiy , John Stultz , Gregory Clement , Michael Chan , "linux-arm-kernel@lists.infradead.org" , Alessandro Zummo , Barry Song , Support Opensource , "netdev@vger.kernel.org" , "Rafael J. Wysocki" , "linux-kernel@vger.kernel.org" , Steve Twiss , Maxime Ripard Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions Message-ID: <20170621075152.GA15996@amd> References: <20170620213507.urobmtg34vzubrdq@piout.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1799 Lines: 58 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > > 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") > >=20 > > I think tglx had a plan for offsetting the time at some point so 32-bit > > platform can pass 2038 properly. >=20 > Yes, but there are still quite some issues to solve there: >=20 > 1) How do you tell the system that it should apply the offset in the > first place, i.e at boot time before NTP or any other mechanism can > correct it? I'd not do offset. Instead, I'd select a threshold (perhaps year of release of given kernel?) and if (rtc_time < year_of_release_of_kernel) rtc_time +=3D 0x100000000; Ok, we'll have to move away from "rtc_time =3D=3D 0 indicates zero", as seen in some drivers. > 2) Deal with creative vendors who have their own idea about the 'sta= rt > of the epoch' If someone uses different threshold, well, there will be confusion. But only for users that have their rtc set to the past, which is quite unusual. Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAllKJZgACgkQMOfwapXb+vKcSACeKjx9YgZ8vE/6kkH+mZDPeoMx BPIAnRnqcPYJuL+92glv1bkWRQ7bPmio =FHDU -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF--