Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752778AbdFUJgO (ORCPT ); Wed, 21 Jun 2017 05:36:14 -0400 Received: from pandora.armlinux.org.uk ([78.32.30.218]:45272 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751223AbdFUJgL (ORCPT ); Wed, 21 Jun 2017 05:36:11 -0400 Date: Wed, 21 Jun 2017 10:35:49 +0100 From: Russell King - ARM Linux To: David Laight Cc: Benjamin Gaignard , Alexandre Belloni , Baruch Siach , "patches@opensource.wolfsonmicro.com" , Linus Walleij , "linux-tegra@vger.kernel.org" , Thierry Reding , Pavel Machek , Thomas Gleixner , "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: <20170621093549.GQ4902@n2100.armlinux.org.uk> References: <20170620100348.zh4ygvjjgnhxvmvl@piout.net> <20170620121011.GA13221@amd> <20170620122400.sm7qqvwyj6cuzarw@piout.net> <20170620132620.GA16881@amd> <6ED8E3B22081A4459DAC7699F3695FB7018CD96FCD@SW-EX-MBX02.diasemi.com> <20170620134458.GA10104@amd> <20170620134827.ubvzhh25klaotupv@piout.net> <20170620211536.GM4902@n2100.armlinux.org.uk> <063D6719AE5E284EB5DD2968C1650D6DD00278C0@AcuExch.aculab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DD00278C0@AcuExch.aculab.com> 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: 2092 Lines: 44 On Wed, Jun 21, 2017 at 09:26:51AM +0000, David Laight wrote: > From: Russell King - ARM Linux > > Sent: 20 June 2017 22:16 > .. > > Consider that at the moment, we define the 32-bit RTC representation to > > start at a well known epoch. We _could_ decide that when it wraps to > > 0x80000000 seconds, we'll define the lower 0x40000000 seconds to mean > > dates in the future - and keep rolling that forward each time we cross > > another 0x40000000 seconds. Unless someone invents a real time machine, > > we shouldn't need to set a modern RTC back to 1970. > > True, just treating the value as unsigned gives another 67 years. We _already_ do treat it as an unsigned number, so already the panicing about 2038 is complete and utter nonsense - that's why I've been consistently stating the 2106 date. > If a 32bit RTC is programmed with the low 32bits of the 64bit 'seconds > since 1970' the kernel should have no real difficulty sorting out the > high bits from other available information. Right, but converting all the 32-bit conversion functions to 64-bit means that rather than "sorting out" that from the core RTC driver, we have to implement solutions in each and every driver. While that may appear to be a good idea, many RTCs that are 32-bit counters do not themselves have additional non-volatile storage, so it means that we're ending up with a lot of RTC specific hacks to go and get the additional information from some other driver elsewhere in the system. > Problems with things like the x86 bios setting the rtc to stupid values > are another matter. Forget x86, the RTC there does not store time as a 32-bit integer, it's stored as its component values, and there's non-volatile memory attached to the RTC. Hence, it's out of scope of "what to do about RTCs that store time in 32-bit format" and also out of scope of "what to do about RTC drivers that use the 32-bit time conversion function." -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.