From mboxrd@z Thu Jan 1 00:00:00 1970 From: Russell King - ARM Linux Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions Date: Wed, 21 Jun 2017 10:35:49 +0100 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 Return-path: Content-Disposition: inline In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DD00278C0-VkEWCZq2GCInGFn1LkZF6NBPR1lH4CV8@public.gmane.org> Sender: linux-tegra-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: David Laight Cc: Benjamin Gaignard , Alexandre Belloni , Baruch Siach , "patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org" , Linus Walleij , "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Thierry Reding , Pavel Machek , Thomas Gleixner , "x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org" , Jonathan Hunter , Chen-Yu Tsai , Ingo Molnar , Sylvain Lemieux , Sebastian Hesselbarth , Len Brown , "linaro-kernel-cunTk1MwBs8s++Sfvej+rw@public.gmane.org" List-Id: linux-tegra@vger.kernel.org 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. From mboxrd@z Thu Jan 1 00:00:00 1970 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 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk. [2001:4d48:ad52:3201:214:fdff:fe10:1be6]) by gmr-mx.google.com with ESMTPS id 143si3793303wmr.0.2017.06.21.02.36.30 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 21 Jun 2017 02:36:30 -0700 (PDT) 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: [rtc-linux] 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="UTF-8" In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DD00278C0@AcuExch.aculab.com> Sender: Russell King - ARM Linux Reply-To: rtc-linux@googlegroups.com List-ID: List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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. -- You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups "rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. From mboxrd@z Thu Jan 1 00:00:00 1970 From: linux@armlinux.org.uk (Russell King - ARM Linux) Date: Wed, 21 Jun 2017 10:35:49 +0100 Subject: [PATCH 00/51] rtc: stop using rtc deprecated functions In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DD00278C0@AcuExch.aculab.com> 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> Message-ID: <20170621093549.GQ4902@n2100.armlinux.org.uk> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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.