From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexandre Belloni Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions Date: Tue, 20 Jun 2017 23:35:07 +0200 Message-ID: <20170620213507.urobmtg34vzubrdq@piout.net> Reply-To: rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Sender: rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Content-Disposition: inline List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , To: Russell King - ARM Linux Cc: Benjamin Gaignard , 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" , Jason Cooper , "rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org" , "linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: linux-tegra@vger.kernel.org On 20/06/2017 at 22:15:36 +0100, Russell King - ARM Linux wrote: > On Tue, Jun 20, 2017 at 05:07:46PM +0200, Benjamin Gaignard wrote: > > 2017-06-20 15:48 GMT+02:00 Alexandre Belloni > > : > > >> Yes, that's argument against changing rtc _drivers_ for hardware that > > >> can not do better than 32bit. For generic code (such as 44/51 sysfs, > > >> 51/51 suspend test), the change still makes sense. > > > > What I had in mind when writing those patches was to remove the limitations > > coming from those functions usage, even more since they been marked has > > deprecated. > > I'd say that they should not be marked as deprecated. They're entirely > appropriate for use with hardware that only supports a 32-bit > representation of time. > > It's entirely reasonable to fix the ones that use other representations > that exceed that, but for those which do not, we need to keep using the > 32-bit versions. Doing so actually gives us _more_ flexibility in the > future. > > 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. > 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") I think tglx had a plan for offsetting the time at some point so 32-bit platform can pass 2038 properly. My opinion is that as long as userspace is not ready to handle those dates, it doesn't really matter because it is quite unlikely that anything will be able to continue running anyway. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit https://groups.google.com/d/optout. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752701AbdFTVfn (ORCPT ); Tue, 20 Jun 2017 17:35:43 -0400 Received: from mail.free-electrons.com ([62.4.15.54]:39873 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752002AbdFTVfl (ORCPT ); Tue, 20 Jun 2017 17:35:41 -0400 Date: Tue, 20 Jun 2017 23:35:07 +0200 From: Alexandre Belloni To: Russell King - ARM Linux Cc: Benjamin Gaignard , 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: <20170620213507.urobmtg34vzubrdq@piout.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline zOIn-Reply-To: <20170620211536.GM4902@n2100.armlinux.org.uk> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 20/06/2017 at 22:15:36 +0100, Russell King - ARM Linux wrote: > On Tue, Jun 20, 2017 at 05:07:46PM +0200, Benjamin Gaignard wrote: > > 2017-06-20 15:48 GMT+02:00 Alexandre Belloni > > : > > >> Yes, that's argument against changing rtc _drivers_ for hardware that > > >> can not do better than 32bit. For generic code (such as 44/51 sysfs, > > >> 51/51 suspend test), the change still makes sense. > > > > What I had in mind when writing those patches was to remove the limitations > > coming from those functions usage, even more since they been marked has > > deprecated. > > I'd say that they should not be marked as deprecated. They're entirely > appropriate for use with hardware that only supports a 32-bit > representation of time. > > It's entirely reasonable to fix the ones that use other representations > that exceed that, but for those which do not, we need to keep using the > 32-bit versions. Doing so actually gives us _more_ flexibility in the > future. > > 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. > 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") I think tglx had a plan for offsetting the time at some point so 32-bit platform can pass 2038 properly. My opinion is that as long as userspace is not ready to handle those dates, it doesn't really matter because it is quite unlikely that anything will be able to continue running anyway. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Sender: rtc-linux@googlegroups.com Received: from mail.free-electrons.com (mail.free-electrons.com. [62.4.15.54]) by gmr-mx.google.com with ESMTP id m189si3196184wma.6.2017.06.20.14.35.39 for ; Tue, 20 Jun 2017 14:35:39 -0700 (PDT) Date: Tue, 20 Jun 2017 23:35:07 +0200 From: Alexandre Belloni To: Russell King - ARM Linux Cc: Benjamin Gaignard , 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: <20170620213507.urobmtg34vzubrdq@piout.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Reply-To: rtc-linux@googlegroups.com List-ID: List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , On 20/06/2017 at 22:15:36 +0100, Russell King - ARM Linux wrote: > On Tue, Jun 20, 2017 at 05:07:46PM +0200, Benjamin Gaignard wrote: > > 2017-06-20 15:48 GMT+02:00 Alexandre Belloni > > : > > >> Yes, that's argument against changing rtc _drivers_ for hardware that > > >> can not do better than 32bit. For generic code (such as 44/51 sysfs, > > >> 51/51 suspend test), the change still makes sense. > > > > What I had in mind when writing those patches was to remove the limitations > > coming from those functions usage, even more since they been marked has > > deprecated. > > I'd say that they should not be marked as deprecated. They're entirely > appropriate for use with hardware that only supports a 32-bit > representation of time. > > It's entirely reasonable to fix the ones that use other representations > that exceed that, but for those which do not, we need to keep using the > 32-bit versions. Doing so actually gives us _more_ flexibility in the > future. > > 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. > 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") I think tglx had a plan for offsetting the time at some point so 32-bit platform can pass 2038 properly. My opinion is that as long as userspace is not ready to handle those dates, it doesn't really matter because it is quite unlikely that anything will be able to continue running anyway. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- 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: Alexandre Belloni Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions Date: Tue, 20 Jun 2017 23:35:07 +0200 Message-ID: <20170620213507.urobmtg34vzubrdq@piout.net> Reply-To: rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: Benjamin Gaignard , 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" , Jason Cooper , "rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org" , "linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Hans Ulli Kroll < To: Russell King - ARM Linux Return-path: Sender: rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Content-Disposition: inline List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , List-Id: netdev.vger.kernel.org On 20/06/2017 at 22:15:36 +0100, Russell King - ARM Linux wrote: > On Tue, Jun 20, 2017 at 05:07:46PM +0200, Benjamin Gaignard wrote: > > 2017-06-20 15:48 GMT+02:00 Alexandre Belloni > > : > > >> Yes, that's argument against changing rtc _drivers_ for hardware that > > >> can not do better than 32bit. For generic code (such as 44/51 sysfs, > > >> 51/51 suspend test), the change still makes sense. > > > > What I had in mind when writing those patches was to remove the limitations > > coming from those functions usage, even more since they been marked has > > deprecated. > > I'd say that they should not be marked as deprecated. They're entirely > appropriate for use with hardware that only supports a 32-bit > representation of time. > > It's entirely reasonable to fix the ones that use other representations > that exceed that, but for those which do not, we need to keep using the > 32-bit versions. Doing so actually gives us _more_ flexibility in the > future. > > 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. > 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") I think tglx had a plan for offsetting the time at some point so 32-bit platform can pass 2038 properly. My opinion is that as long as userspace is not ready to handle those dates, it doesn't really matter because it is quite unlikely that anything will be able to continue running anyway. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit https://groups.google.com/d/optout.