From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Machek Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions Date: Wed, 21 Jun 2017 08:34:43 +0200 Message-ID: <20170621063443.GA4862@localhost> References: <20170620213507.urobmtg34vzubrdq@piout.net> <20170621075152.GA15996@amd> <20170621083907.y3gadsmsoufa5niv@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 In-Reply-To: <20170621083907.y3gadsmsoufa5niv-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org> List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , To: Alexandre Belloni Cc: Thomas Gleixner , Russell King - ARM Linux , Benjamin Gaignard , Baruch Siach , "patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org" , Linus Walleij , "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Thierry Reding , "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 Hi! > > > > I think tglx had a plan for offsetting the time at some point so 32-bit > > > > platform can pass 2038 properly. > > > > > > 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? > > > > 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 += 0x100000000; > > > > Ok, we'll have to move away from "rtc_time == 0 indicates zero", as > > seen in some drivers. > > > > > 2) Deal with creative vendors who have their own idea about the 'start > > > 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. > > > > Or not, having an RTC set in the past is actually quite common. I'd find > it weird to have a new device boot and be set to a date in the future. ...but still better than board stuck in the past, no? > Also note that the threshold or offset thing may seem like a good idea > but fails with many RTCs because of how they handle leap years. Well, you can still convert time from rtc to unix time, then do adjustment there. Anyway, I guess it would be cool for rtc drivers to annotate what limits underlying storage has to the common code, so that we can do fixups once per class, not once per driver. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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 S1751166AbdFULgM (ORCPT ); Wed, 21 Jun 2017 07:36:12 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:33658 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750859AbdFULgJ (ORCPT ); Wed, 21 Jun 2017 07:36:09 -0400 Date: Wed, 21 Jun 2017 08:34:43 +0200 From: Pavel Machek To: Alexandre Belloni Cc: Thomas Gleixner , 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: <20170621063443.GA4862@localhost> References: <20170620213507.urobmtg34vzubrdq@piout.net> <20170621075152.GA15996@amd> <20170621083907.y3gadsmsoufa5niv@piout.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170621083907.y3gadsmsoufa5niv@piout.net> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi! > > > > I think tglx had a plan for offsetting the time at some point so 32-bit > > > > platform can pass 2038 properly. > > > > > > 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? > > > > 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 += 0x100000000; > > > > Ok, we'll have to move away from "rtc_time == 0 indicates zero", as > > seen in some drivers. > > > > > 2) Deal with creative vendors who have their own idea about the 'start > > > 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. > > > > Or not, having an RTC set in the past is actually quite common. I'd find > it weird to have a new device boot and be set to a date in the future. ...but still better than board stuck in the past, no? > Also note that the threshold or offset thing may seem like a good idea > but fails with many RTCs because of how they handle leap years. Well, you can still convert time from rtc to unix time, then do adjustment there. Anyway, I guess it would be cool for rtc drivers to annotate what limits underlying storage has to the common code, so that we can do fixups once per class, not once per driver. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Sender: rtc-linux@googlegroups.com Received: from atrey.karlin.mff.cuni.cz (atrey.karlin.mff.cuni.cz. [195.113.26.193]) by gmr-mx.google.com with ESMTPS id 140si4850145wmr.2.2017.06.21.04.36.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jun 2017 04:36:07 -0700 (PDT) Date: Wed, 21 Jun 2017 08:34:43 +0200 From: Pavel Machek To: Alexandre Belloni Cc: Thomas Gleixner , 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: [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions Message-ID: <20170621063443.GA4862@localhost> References: <20170620213507.urobmtg34vzubrdq@piout.net> <20170621075152.GA15996@amd> <20170621083907.y3gadsmsoufa5niv@piout.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" In-Reply-To: <20170621083907.y3gadsmsoufa5niv@piout.net> Reply-To: rtc-linux@googlegroups.com List-ID: List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , Hi! > > > > I think tglx had a plan for offsetting the time at some point so 32-bit > > > > platform can pass 2038 properly. > > > > > > 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? > > > > 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 += 0x100000000; > > > > Ok, we'll have to move away from "rtc_time == 0 indicates zero", as > > seen in some drivers. > > > > > 2) Deal with creative vendors who have their own idea about the 'start > > > 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. > > > > Or not, having an RTC set in the past is actually quite common. I'd find > it weird to have a new device boot and be set to a date in the future. ...but still better than board stuck in the past, no? > Also note that the threshold or offset thing may seem like a good idea > but fails with many RTCs because of how they handle leap years. Well, you can still convert time from rtc to unix time, then do adjustment there. Anyway, I guess it would be cool for rtc drivers to annotate what limits underlying storage has to the common code, so that we can do fixups once per class, not once per driver. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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: Pavel Machek Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions Date: Wed, 21 Jun 2017 08:34:43 +0200 Message-ID: <20170621063443.GA4862@localhost> References: <20170620213507.urobmtg34vzubrdq@piout.net> <20170621075152.GA15996@amd> <20170621083907.y3gadsmsoufa5niv@piout.net> Reply-To: rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: Thomas Gleixner , Russell King - ARM Linux , Benjamin Gaignard , Baruch Siach , "patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org" , Linus Walleij , "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Thierry Reding , "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" Return-path: Sender: rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Content-Disposition: inline In-Reply-To: <20170621083907.y3gadsmsoufa5niv-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org> List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , List-Id: netdev.vger.kernel.org Hi! > > > > I think tglx had a plan for offsetting the time at some point so 32-bit > > > > platform can pass 2038 properly. > > > > > > 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? > > > > 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 += 0x100000000; > > > > Ok, we'll have to move away from "rtc_time == 0 indicates zero", as > > seen in some drivers. > > > > > 2) Deal with creative vendors who have their own idea about the 'start > > > 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. > > > > Or not, having an RTC set in the past is actually quite common. I'd find > it weird to have a new device boot and be set to a date in the future. ...but still better than board stuck in the past, no? > Also note that the threshold or offset thing may seem like a good idea > but fails with many RTCs because of how they handle leap years. Well, you can still convert time from rtc to unix time, then do adjustment there. Anyway, I guess it would be cool for rtc drivers to annotate what limits underlying storage has to the common code, so that we can do fixups once per class, not once per driver. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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 From: pavel@ucw.cz (Pavel Machek) Date: Wed, 21 Jun 2017 08:34:43 +0200 Subject: [PATCH 00/51] rtc: stop using rtc deprecated functions In-Reply-To: <20170621083907.y3gadsmsoufa5niv@piout.net> References: <20170620213507.urobmtg34vzubrdq@piout.net> <20170621075152.GA15996@amd> <20170621083907.y3gadsmsoufa5niv@piout.net> Message-ID: <20170621063443.GA4862@localhost> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi! > > > > I think tglx had a plan for offsetting the time at some point so 32-bit > > > > platform can pass 2038 properly. > > > > > > 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? > > > > 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 += 0x100000000; > > > > Ok, we'll have to move away from "rtc_time == 0 indicates zero", as > > seen in some drivers. > > > > > 2) Deal with creative vendors who have their own idea about the 'start > > > 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. > > > > Or not, having an RTC set in the past is actually quite common. I'd find > it weird to have a new device boot and be set to a date in the future. ...but still better than board stuck in the past, no? > Also note that the threshold or offset thing may seem like a good idea > but fails with many RTCs because of how they handle leap years. Well, you can still convert time from rtc to unix time, then do adjustment there. Anyway, I guess it would be cool for rtc drivers to annotate what limits underlying storage has to the common code, so that we can do fixups once per class, not once per driver. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html