Date: Tue, 20 Jun 2017 23:38:59 +0100
From: Russell King - ARM Linux <linux@armlinux.org.uk>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>,
        Benjamin Gaignard <benjamin.gaignard@linaro.org>,
        Baruch Siach <baruch@tkos.co.il>,
        "patches@opensource.wolfsonmicro.com" 
        <patches@opensource.wolfsonmicro.com>,
        Linus Walleij <linus.walleij@linaro.org>,
        "linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
        Thierry Reding <thierry.reding@gmail.com>, Pavel Machek <pavel@ucw.cz>,
        "x86@kernel.org" <x86@kernel.org>,
        Jonathan Hunter <jonathanh@nvidia.com>, Chen-Yu Tsai <wens@csie.org>,
        Ingo Molnar <mingo@redhat.com>,
        Sylvain Lemieux <slemieux.tyco@gmail.com>,
        Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
        Len Brown <len.brown@intel.com>,
        "linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>,
        Jason Cooper <jason@lakedaemon.net>,
        "rtc-linux@googlegroups.com" <rtc-linux@googlegroups.com>,
        "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
        Hans Ulli Kroll <ulli.kroll@googlemail.com>,
        "adi-buildroot-devel@lists.sourceforge.net" 
        <adi-buildroot-devel@lists.sourceforge.net>,
        Vladimir Zapolskiy <vz@mleia.com>,
        John Stultz <john.stultz@linaro.org>,
        Gregory Clement <gregory.clement@free-electrons.com>,
        Michael Chan <michael.chan@broadcom.com>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        Alessandro Zummo <a.zummo@towertech.it>,
        Barry Song <baohua@kernel.org>,
        Support Opensource <Support.Opensource@diasemi.com>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "Rafael J. Wysocki" <rjw@rjwysocki.net>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Steve Twiss <stwiss.opensource@diasemi.com>,
        Maxime Ripard <maxime.ripard@free-electrons.com>
Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
Message-ID: <20170620223859.GO4902@n2100.armlinux.org.uk>
References: <20170620213507.urobmtg34vzubrdq@piout.net>
 <alpine.DEB.2.20.1706202343120.2157@nanos>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.20.1706202343120.2157@nanos>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1292
Lines: 30

On Wed, Jun 21, 2017 at 12:00:30AM +0200, Thomas Gleixner wrote:
> Yes, but there are still quite some issues to solve there:
> 
>      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?
> 
>      2) Deal with creative vendors who have their own idea about the 'start
>      	of the epoch'
> 	
>      3) Add the information of wraparound time to the rtc device which
>      	needs to be filled in for each device. That way the rtc_***
>      	accessor functions can deal with them whether they wrap in 2038 or
>      	2100 or whatever.
> 
> #3 is the simplest problem of them :)	

Well, if there's additional non-volatile storage, you can store
additional information in there, but you still need the RTC
subsystem to be aware that the hardware is only 32-bit capable.

You'd also still need something along the lines I detailed
(redefining what dates the past 32-bit values indicate) to cope
with the RTC being set backwards after the machine thinks (possibly
incorrectly) that the date has jumped forwards.

-- 
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.