* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
@ 2017-06-20 21:35 ` Alexandre Belloni
0 siblings, 0 replies; 106+ messages in thread
From: Alexandre Belloni @ 2017-06-20 21:35 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Benjamin Gaignard, Baruch Siach,
patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E,
Linus Walleij, linux-tegra-u79uwXL29TY76Z2rM5mHXA,
Thierry Reding, Pavel Machek, Thomas Gleixner,
x86-DgEjT+Ai2ygdnm+yROfE0A, Jonathan Hunter, Chen-Yu Tsai,
Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Jason Cooper,
rtc-linux-/JYPxA39Uh5TLH3MbocFFw,
linux-pm-u79uwXL29TY76Z2rM5mHXA
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
> > <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>:
> > >> 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.
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 21:35 ` Alexandre Belloni 0 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-20 21:35 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Benjamin Gaignard, Baruch Siach, patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E, Linus Walleij, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Thierry Reding, Pavel Machek, Thomas Gleixner, x86-DgEjT+Ai2ygdnm+yROfE0A, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Jason Cooper, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, linux-pm-u79uwXL29TY76Z2rM5mHXA, Hans Ulli Kroll 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 > > <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>: > > >> 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 21:35 ` Alexandre Belloni 0 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-20 21:35 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Benjamin Gaignard, Baruch Siach, patches, Linus Walleij, linux-tegra, Thierry Reding, Pavel Machek, Thomas Gleixner, x86, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel, Jason Cooper, rtc-linux, linux-pm, Hans Ulli Kroll, adi-buildroot-devel, Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan, linux-arm-kernel, Alessandro Zummo, Barry Song, Support Opensource, netdev, Rafael J. Wysocki, linux-kernel, Steve Twiss, Maxime Ripard 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 > > <alexandre.belloni@free-electrons.com>: > > >> 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 21:35 ` Alexandre Belloni 0 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-20 21:35 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Benjamin Gaignard, Baruch Siach, patches, Linus Walleij, linux-tegra, Thierry Reding, Pavel Machek, Thomas Gleixner, x86, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel, Jason Cooper, rtc-linux, linux-pm, Hans Ulli Kroll, adi-buildroot-devel, Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan, linux-arm-kernel, Alessandro Zummo, Barry Song, Support Opensource, netdev, Rafael J. Wysocki, linux-kernel, Steve Twiss, Maxime Ripard 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 > > <alexandre.belloni@free-electrons.com>: > > >> 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
[parent not found: <20170620213507.urobmtg34vzubrdq-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org>]
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions 2017-06-20 21:35 ` Alexandre Belloni ` (2 preceding siblings ...) (?) @ 2017-06-20 22:00 ` Thomas Gleixner -1 siblings, 0 replies; 106+ messages in thread From: Thomas Gleixner @ 2017-06-20 22:00 UTC (permalink / raw) To: Alexandre Belloni Cc: Russell King - ARM Linux, Benjamin Gaignard, Baruch Siach, patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E, Linus Walleij, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Thierry Reding, Pavel Machek, x86-DgEjT+Ai2ygdnm+yROfE0A, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Jason Cooper, rtc-linux-/JYPxA39Uh5TLH3MbocFFw On Tue, 20 Jun 2017, Alexandre Belloni wrote: > 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 > > > <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>: > > > >> 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. 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 :) > 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. That's a different story. Making the kernel y2038 ready in general is a good thing. Whether userspace will be ready by then or not is completely irrelevant. Thanks, tglx -- 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 22:00 ` Thomas Gleixner 0 siblings, 0 replies; 106+ messages in thread From: Thomas Gleixner @ 2017-06-20 22:00 UTC (permalink / raw) To: linux-arm-kernel On Tue, 20 Jun 2017, Alexandre Belloni wrote: > 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 > > > <alexandre.belloni@free-electrons.com>: > > > >> 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. 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 :) > 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. That's a different story. Making the kernel y2038 ready in general is a good thing. Whether userspace will be ready by then or not is completely irrelevant. Thanks, tglx ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 22:00 ` Thomas Gleixner 0 siblings, 0 replies; 106+ messages in thread From: Thomas Gleixner @ 2017-06-20 22:00 UTC (permalink / raw) To: Alexandre Belloni Cc: Russell King - ARM Linux, Benjamin Gaignard, Baruch Siach, patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E, Linus Walleij, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Thierry Reding, Pavel Machek, x86-DgEjT+Ai2ygdnm+yROfE0A, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Jason Cooper, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, On Tue, 20 Jun 2017, Alexandre Belloni wrote: > 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 > > > <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>: > > > >> 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. 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 :) > 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. That's a different story. Making the kernel y2038 ready in general is a good thing. Whether userspace will be ready by then or not is completely irrelevant. Thanks, tglx -- 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 22:00 ` Thomas Gleixner 0 siblings, 0 replies; 106+ messages in thread From: Thomas Gleixner @ 2017-06-20 22:00 UTC (permalink / raw) To: Alexandre Belloni Cc: Russell King - ARM Linux, Benjamin Gaignard, Baruch Siach, patches, Linus Walleij, linux-tegra, Thierry Reding, Pavel Machek, x86, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel, Jason Cooper, rtc-linux, linux-pm, Hans Ulli Kroll, adi-buildroot-devel, Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan, linux-arm-kernel, Alessandro Zummo, Barry Song, Support Opensource, netdev, Rafael J. Wysocki, linux-kernel, Steve Twiss, Maxime Ripard On Tue, 20 Jun 2017, Alexandre Belloni wrote: > 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 > > > <alexandre.belloni@free-electrons.com>: > > > >> 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. 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 :) > 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. That's a different story. Making the kernel y2038 ready in general is a good thing. Whether userspace will be ready by then or not is completely irrelevant. Thanks, tglx -- 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 22:00 ` Thomas Gleixner 0 siblings, 0 replies; 106+ messages in thread From: Thomas Gleixner @ 2017-06-20 22:00 UTC (permalink / raw) To: Alexandre Belloni Cc: Russell King - ARM Linux, Benjamin Gaignard, Baruch Siach, patches, Linus Walleij, linux-tegra, Thierry Reding, Pavel Machek, x86, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel, Jason Cooper, rtc-linux, linux-pm, Hans Ulli Kroll, adi-buildroot-devel, Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan, linux-arm-kernel, Alessandro Zummo, Barry Song, Support Opensource, netdev, Rafael J. Wysocki, linux-kernel, Steve Twiss, Maxime Ripard On Tue, 20 Jun 2017, Alexandre Belloni wrote: > 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 > > > <alexandre.belloni@free-electrons.com>: > > > >> 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. 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 :) > 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. That's a different story. Making the kernel y2038 ready in general is a good thing. Whether userspace will be ready by then or not is completely irrelevant. Thanks, tglx ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions 2017-06-20 22:00 ` Thomas Gleixner ` (2 preceding siblings ...) (?) @ 2017-06-20 22:38 ` Russell King - ARM Linux -1 siblings, 0 replies; 106+ messages in thread From: Russell King - ARM Linux @ 2017-06-20 22:38 UTC (permalink / raw) To: Thomas Gleixner Cc: Alexandre Belloni, Benjamin Gaignard, Baruch Siach, patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E, Linus Walleij, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Thierry Reding, Pavel Machek, x86-DgEjT+Ai2ygdnm+yROfE0A, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Jason Cooper 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 22:38 ` Russell King - ARM Linux 0 siblings, 0 replies; 106+ messages in thread From: Russell King - ARM Linux @ 2017-06-20 22:38 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 22:38 ` Russell King - ARM Linux 0 siblings, 0 replies; 106+ messages in thread From: Russell King - ARM Linux @ 2017-06-20 22:38 UTC (permalink / raw) To: Thomas Gleixner Cc: Alexandre Belloni, Benjamin Gaignard, Baruch Siach, patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E, Linus Walleij, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Thierry Reding, Pavel Machek, x86-DgEjT+Ai2ygdnm+yROfE0A, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Jason Cooper 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 22:38 ` Russell King - ARM Linux 0 siblings, 0 replies; 106+ messages in thread From: Russell King - ARM Linux @ 2017-06-20 22:38 UTC (permalink / raw) To: Thomas Gleixner Cc: Alexandre Belloni, Benjamin Gaignard, Baruch Siach, patches, Linus Walleij, linux-tegra, Thierry Reding, Pavel Machek, x86, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel, Jason Cooper, rtc-linux, linux-pm, Hans Ulli Kroll, adi-buildroot-devel, Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan, linux-arm-kernel, Alessandro Zummo, Barry Song, Support Opensource, netdev, Rafael J. Wysocki, linux-kernel, Steve Twiss, Maxime Ripard 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. -- 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 22:38 ` Russell King - ARM Linux 0 siblings, 0 replies; 106+ messages in thread From: Russell King - ARM Linux @ 2017-06-20 22:38 UTC (permalink / raw) To: Thomas Gleixner Cc: Alexandre Belloni, Benjamin Gaignard, Baruch Siach, patches, Linus Walleij, linux-tegra, Thierry Reding, Pavel Machek, x86, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel, Jason Cooper, rtc-linux, linux-pm, Hans Ulli Kroll, adi-buildroot-devel, Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan, linux-arm-kernel, Alessandro Zummo, Barry Song, Support Opensource, netdev, Rafael J. Wysocki, linux-kernel, Steve Twiss, Maxime Ripard 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions 2017-06-20 22:00 ` Thomas Gleixner ` (2 preceding siblings ...) (?) @ 2017-06-21 7:51 ` Pavel Machek -1 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-21 7:51 UTC (permalink / raw) To: Thomas Gleixner Cc: Alexandre Belloni, Russell King - ARM Linux, Benjamin Gaignard, Baruch Siach, patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E, Linus Walleij, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Thierry Reding, x86-DgEjT+Ai2ygdnm+yROfE0A, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Jason Cooper, rtc-linux-/JYPxA39Uh5TLH3MbocFFw [-- Attachment #1: Type: text/plain, Size: 1867 bytes --] Hi! > > 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. > > 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. Pavel -- (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. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 7:51 ` Pavel Machek 0 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-21 7:51 UTC (permalink / raw) To: linux-arm-kernel Hi! > > 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. > > 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. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170621/7837e096/attachment-0001.sig> ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 7:51 ` Pavel Machek 0 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-21 7:51 UTC (permalink / raw) To: Thomas Gleixner Cc: Alexandre Belloni, Russell King - ARM Linux, Benjamin Gaignard, Baruch Siach, patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E, Linus Walleij, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Thierry Reding, x86-DgEjT+Ai2ygdnm+yROfE0A, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Jason Cooper, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [-- Attachment #1: Type: text/plain, Size: 1867 bytes --] Hi! > > 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. > > 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. Pavel -- (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. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 7:51 ` Pavel Machek 0 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-21 7:51 UTC (permalink / raw) To: Thomas Gleixner Cc: Alexandre Belloni, Russell King - ARM Linux, Benjamin Gaignard, Baruch Siach, patches, Linus Walleij, linux-tegra, Thierry Reding, x86, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel, Jason Cooper, rtc-linux, linux-pm, Hans Ulli Kroll, adi-buildroot-devel, Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan, linux-arm-kernel, Alessandro Zummo, Barry Song, Support Opensource, netdev, Rafael J. Wysocki, linux-kernel, Steve Twiss, Maxime Ripard [-- Attachment #1: Type: text/plain, Size: 1835 bytes --] Hi! > > 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. > > 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. Pavel -- (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. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 7:51 ` Pavel Machek 0 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-21 7:51 UTC (permalink / raw) To: Thomas Gleixner Cc: Alexandre Belloni, Russell King - ARM Linux, Benjamin Gaignard, Baruch Siach, patches, Linus Walleij, linux-tegra, Thierry Reding, x86, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel, Jason Cooper, rtc-linux, linux-pm, Hans Ulli Kroll, adi-buildroot-devel, Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan, linux-arm-kernel, Alessandro Zummo, Barry Song, Support Opensource, netdev, Rafael J. Wysocki, linux-kernel, Steve Twiss, Maxime Ripard [-- Attachment #1: Type: text/plain, Size: 1356 bytes --] Hi! > > 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. > > 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. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions 2017-06-21 7:51 ` Pavel Machek ` (2 preceding siblings ...) (?) @ 2017-06-21 8:39 ` Alexandre Belloni -1 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-21 8:39 UTC (permalink / raw) To: Pavel Machek Cc: Thomas Gleixner, Russell King - ARM Linux, Benjamin Gaignard, Baruch Siach, patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E, Linus Walleij, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Thierry Reding, x86-DgEjT+Ai2ygdnm+yROfE0A, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Jason Cooper, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org On 21/06/2017 at 09:51:52 +0200, Pavel Machek wrote: > Hi! > > > > 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. > > > > 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. 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. -- 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 8:39 ` Alexandre Belloni 0 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-21 8:39 UTC (permalink / raw) To: linux-arm-kernel On 21/06/2017 at 09:51:52 +0200, Pavel Machek wrote: > Hi! > > > > 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. > > > > 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. 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. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 8:39 ` Alexandre Belloni 0 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-21 8:39 UTC (permalink / raw) To: Pavel Machek Cc: Thomas Gleixner, Russell King - ARM Linux, Benjamin Gaignard, Baruch Siach, patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E, Linus Walleij, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Thierry Reding, x86-DgEjT+Ai2ygdnm+yROfE0A, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Jason Cooper, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org On 21/06/2017 at 09:51:52 +0200, Pavel Machek wrote: > Hi! > > > > 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. > > > > 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. 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. -- 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 8:39 ` Alexandre Belloni 0 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-21 8:39 UTC (permalink / raw) To: Pavel Machek Cc: Thomas Gleixner, Russell King - ARM Linux, Benjamin Gaignard, Baruch Siach, patches, Linus Walleij, linux-tegra, Thierry Reding, x86, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel, Jason Cooper, rtc-linux, linux-pm, Hans Ulli Kroll, adi-buildroot-devel, Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan, linux-arm-kernel, Alessandro Zummo, Barry Song, Support Opensource, netdev, Rafael J. Wysocki, linux-kernel, Steve Twiss, Maxime Ripard On 21/06/2017 at 09:51:52 +0200, Pavel Machek wrote: > Hi! > > > > 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. > > > > 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. 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. -- 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 8:39 ` Alexandre Belloni 0 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-21 8:39 UTC (permalink / raw) To: Pavel Machek Cc: Thomas Gleixner, Russell King - ARM Linux, Benjamin Gaignard, Baruch Siach, patches, Linus Walleij, linux-tegra, Thierry Reding, x86, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel, Jason Cooper, rtc-linux, linux-pm, Hans Ulli Kroll, adi-buildroot-devel, Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan, linux-arm-kernel, Alessandro Zummo, Barry Song, Support Opensource, netdev, Rafael J. Wysocki, linux-kernel, Steve Twiss, Maxime Ripard On 21/06/2017 at 09:51:52 +0200, Pavel Machek wrote: > Hi! > > > > 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. > > > > 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. 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. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 106+ messages in thread
[parent not found: <20170621083907.y3gadsmsoufa5niv-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org>]
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions 2017-06-21 8:39 ` Alexandre Belloni ` (2 preceding siblings ...) (?) @ 2017-06-21 6:34 ` Pavel Machek -1 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-21 6:34 UTC (permalink / raw) To: Alexandre Belloni Cc: Thomas Gleixner, Russell King - ARM Linux, Benjamin Gaignard, Baruch Siach, patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E, Linus Walleij, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Thierry Reding, x86-DgEjT+Ai2ygdnm+yROfE0A, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Jason Cooper, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 6:34 ` Pavel Machek 0 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-21 6:34 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 6:34 ` Pavel Machek 0 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-21 6:34 UTC (permalink / raw) To: Alexandre Belloni Cc: Thomas Gleixner, Russell King - ARM Linux, Benjamin Gaignard, Baruch Siach, patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E, Linus Walleij, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Thierry Reding, x86-DgEjT+Ai2ygdnm+yROfE0A, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Jason Cooper, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 6:34 ` Pavel Machek 0 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-21 6:34 UTC (permalink / raw) To: Alexandre Belloni Cc: Thomas Gleixner, Russell King - ARM Linux, Benjamin Gaignard, Baruch Siach, patches, Linus Walleij, linux-tegra, Thierry Reding, x86, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel, Jason Cooper, rtc-linux, linux-pm, Hans Ulli Kroll, adi-buildroot-devel, Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan, linux-arm-kernel, Alessandro Zummo, Barry Song, Support Opensource, netdev, Rafael J. Wysocki, linux-kernel, Steve Twiss, Maxime Ripard 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 6:34 ` Pavel Machek 0 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-21 6:34 UTC (permalink / raw) To: Alexandre Belloni Cc: Thomas Gleixner, Russell King - ARM Linux, Benjamin Gaignard, Baruch Siach, patches, Linus Walleij, linux-tegra, Thierry Reding, x86, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel, Jason Cooper, rtc-linux, linux-pm, Hans Ulli Kroll, adi-buildroot-devel, Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan, linux-arm-kernel, Alessandro Zummo, Barry Song, Support Opensource, netdev, Rafael J. Wysocki, linux-kernel, Steve Twiss, Maxime Ripard 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions 2017-06-21 6:34 ` Pavel Machek ` (2 preceding siblings ...) (?) @ 2017-06-21 12:35 ` Alexandre Belloni -1 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-21 12:35 UTC (permalink / raw) To: Pavel Machek Cc: Thomas Gleixner, Russell King - ARM Linux, Benjamin Gaignard, Baruch Siach, patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E, Linus Walleij, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Thierry Reding, x86-DgEjT+Ai2ygdnm+yROfE0A, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Jason Cooper, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org On 21/06/2017 at 08:34:43 +0200, Pavel Machek wrote: > 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. > You can only if your machine is running when that happens. If that is not the case, then you lost and your time is not correct anymore. There is currently one rtc doing that kind of trick but it is used as a simple time counter from the beginning. Transitioning is the difficult part. > 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. Yes, I'm in the middle of the whole rework that allows that. I don't understand the sudden urgency of fixing that and the amount of bikeshedding, seeing that the closest cutoff date is actually 31st of december 2069 in the rtc subsystem and that anyway the current 32bit userspace will explode in february 2038. My plan from the beginning was to have something for the next stable. I know nobody can read my mind but again, I don't think there is currently any urgency to change anything. -- 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 12:35 ` Alexandre Belloni 0 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-21 12:35 UTC (permalink / raw) To: linux-arm-kernel On 21/06/2017 at 08:34:43 +0200, Pavel Machek wrote: > 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. > You can only if your machine is running when that happens. If that is not the case, then you lost and your time is not correct anymore. There is currently one rtc doing that kind of trick but it is used as a simple time counter from the beginning. Transitioning is the difficult part. > 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. Yes, I'm in the middle of the whole rework that allows that. I don't understand the sudden urgency of fixing that and the amount of bikeshedding, seeing that the closest cutoff date is actually 31st of december 2069 in the rtc subsystem and that anyway the current 32bit userspace will explode in february 2038. My plan from the beginning was to have something for the next stable. I know nobody can read my mind but again, I don't think there is currently any urgency to change anything. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 12:35 ` Alexandre Belloni 0 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-21 12:35 UTC (permalink / raw) To: Pavel Machek Cc: Thomas Gleixner, Russell King - ARM Linux, Benjamin Gaignard, Baruch Siach, patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E, Linus Walleij, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Thierry Reding, x86-DgEjT+Ai2ygdnm+yROfE0A, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Jason Cooper, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org On 21/06/2017 at 08:34:43 +0200, Pavel Machek wrote: > 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. > You can only if your machine is running when that happens. If that is not the case, then you lost and your time is not correct anymore. There is currently one rtc doing that kind of trick but it is used as a simple time counter from the beginning. Transitioning is the difficult part. > 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. Yes, I'm in the middle of the whole rework that allows that. I don't understand the sudden urgency of fixing that and the amount of bikeshedding, seeing that the closest cutoff date is actually 31st of december 2069 in the rtc subsystem and that anyway the current 32bit userspace will explode in february 2038. My plan from the beginning was to have something for the next stable. I know nobody can read my mind but again, I don't think there is currently any urgency to change anything. -- 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 12:35 ` Alexandre Belloni 0 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-21 12:35 UTC (permalink / raw) To: Pavel Machek Cc: Thomas Gleixner, Russell King - ARM Linux, Benjamin Gaignard, Baruch Siach, patches, Linus Walleij, linux-tegra, Thierry Reding, x86, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel, Jason Cooper, rtc-linux, linux-pm, Hans Ulli Kroll, adi-buildroot-devel, Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan, linux-arm-kernel, Alessandro Zummo, Barry Song, Support Opensource, netdev, Rafael J. Wysocki, linux-kernel, Steve Twiss, Maxime Ripard On 21/06/2017 at 08:34:43 +0200, Pavel Machek wrote: > 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. > You can only if your machine is running when that happens. If that is not the case, then you lost and your time is not correct anymore. There is currently one rtc doing that kind of trick but it is used as a simple time counter from the beginning. Transitioning is the difficult part. > 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. Yes, I'm in the middle of the whole rework that allows that. I don't understand the sudden urgency of fixing that and the amount of bikeshedding, seeing that the closest cutoff date is actually 31st of december 2069 in the rtc subsystem and that anyway the current 32bit userspace will explode in february 2038. My plan from the beginning was to have something for the next stable. I know nobody can read my mind but again, I don't think there is currently any urgency to change anything. -- 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 12:35 ` Alexandre Belloni 0 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-21 12:35 UTC (permalink / raw) To: Pavel Machek Cc: Thomas Gleixner, Russell King - ARM Linux, Benjamin Gaignard, Baruch Siach, patches, Linus Walleij, linux-tegra, Thierry Reding, x86, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel, Jason Cooper, rtc-linux, linux-pm, Hans Ulli Kroll, adi-buildroot-devel, Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan, linux-arm-kernel, Alessandro Zummo, Barry Song, Support Opensource, netdev, Rafael J. Wysocki, linux-kernel, Steve Twiss, Maxime Ripard On 21/06/2017 at 08:34:43 +0200, Pavel Machek wrote: > 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. > You can only if your machine is running when that happens. If that is not the case, then you lost and your time is not correct anymore. There is currently one rtc doing that kind of trick but it is used as a simple time counter from the beginning. Transitioning is the difficult part. > 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. Yes, I'm in the middle of the whole rework that allows that. I don't understand the sudden urgency of fixing that and the amount of bikeshedding, seeing that the closest cutoff date is actually 31st of december 2069 in the rtc subsystem and that anyway the current 32bit userspace will explode in february 2038. My plan from the beginning was to have something for the next stable. I know nobody can read my mind but again, I don't think there is currently any urgency to change anything. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 106+ messages in thread
[parent not found: <20170621123535.b5fvwlydfhnhuqll-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org>]
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions 2017-06-21 12:35 ` Alexandre Belloni ` (2 preceding siblings ...) (?) @ 2017-06-21 18:08 ` Pavel Machek -1 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-21 18:08 UTC (permalink / raw) To: Alexandre Belloni Cc: Thomas Gleixner, Russell King - ARM Linux, Benjamin Gaignard, Baruch Siach, patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E, Linus Walleij, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Thierry Reding, x86-DgEjT+Ai2ygdnm+yROfE0A, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Jason Cooper, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [-- Attachment #1: Type: text/plain, Size: 2294 bytes --] Hi! > > > 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. > > > > You can only if your machine is running when that happens. If that is > not the case, then you lost and your time is not correct anymore. I don't see why that should be a case... as long as you know what RTC does in event of overflow, and it is not something completely crazy. > > 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. > > Yes, I'm in the middle of the whole rework that allows that. > > I don't understand the sudden urgency of fixing that and the amount of > bikeshedding, seeing that the closest cutoff date is actually 31st of > december 2069 in the rtc subsystem and that anyway the current 32bit > userspace will explode in february 2038. > > My plan from the beginning was to have something for the next stable. I > know nobody can read my mind but again, I don't think there is currently > any urgency to change anything. Yes, mind reading is a problem. I can only read minds of ferungulates, and only if they are physicaly near me :-). Best regards, Pavel -- (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. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 18:08 ` Pavel Machek 0 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-21 18:08 UTC (permalink / raw) To: linux-arm-kernel Hi! > > > 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. > > > > You can only if your machine is running when that happens. If that is > not the case, then you lost and your time is not correct anymore. I don't see why that should be a case... as long as you know what RTC does in event of overflow, and it is not something completely crazy. > > 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. > > Yes, I'm in the middle of the whole rework that allows that. > > I don't understand the sudden urgency of fixing that and the amount of > bikeshedding, seeing that the closest cutoff date is actually 31st of > december 2069 in the rtc subsystem and that anyway the current 32bit > userspace will explode in february 2038. > > My plan from the beginning was to have something for the next stable. I > know nobody can read my mind but again, I don't think there is currently > any urgency to change anything. Yes, mind reading is a problem. I can only read minds of ferungulates, and only if they are physicaly near me :-). Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170621/cd332894/attachment.sig> ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 18:08 ` Pavel Machek 0 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-21 18:08 UTC (permalink / raw) To: Alexandre Belloni Cc: Thomas Gleixner, Russell King - ARM Linux, Benjamin Gaignard, Baruch Siach, patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E, Linus Walleij, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Thierry Reding, x86-DgEjT+Ai2ygdnm+yROfE0A, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Jason Cooper, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [-- Attachment #1: Type: text/plain, Size: 2294 bytes --] Hi! > > > 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. > > > > You can only if your machine is running when that happens. If that is > not the case, then you lost and your time is not correct anymore. I don't see why that should be a case... as long as you know what RTC does in event of overflow, and it is not something completely crazy. > > 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. > > Yes, I'm in the middle of the whole rework that allows that. > > I don't understand the sudden urgency of fixing that and the amount of > bikeshedding, seeing that the closest cutoff date is actually 31st of > december 2069 in the rtc subsystem and that anyway the current 32bit > userspace will explode in february 2038. > > My plan from the beginning was to have something for the next stable. I > know nobody can read my mind but again, I don't think there is currently > any urgency to change anything. Yes, mind reading is a problem. I can only read minds of ferungulates, and only if they are physicaly near me :-). Best regards, Pavel -- (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. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 18:08 ` Pavel Machek 0 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-21 18:08 UTC (permalink / raw) To: Alexandre Belloni Cc: Thomas Gleixner, Russell King - ARM Linux, Benjamin Gaignard, Baruch Siach, patches, Linus Walleij, linux-tegra, Thierry Reding, x86, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel, Jason Cooper, rtc-linux, linux-pm, Hans Ulli Kroll, adi-buildroot-devel, Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan, linux-arm-kernel, Alessandro Zummo, Barry Song, Support Opensource, netdev, Rafael J. Wysocki, linux-kernel, Steve Twiss, Maxime Ripard [-- Attachment #1: Type: text/plain, Size: 2262 bytes --] Hi! > > > 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. > > > > You can only if your machine is running when that happens. If that is > not the case, then you lost and your time is not correct anymore. I don't see why that should be a case... as long as you know what RTC does in event of overflow, and it is not something completely crazy. > > 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. > > Yes, I'm in the middle of the whole rework that allows that. > > I don't understand the sudden urgency of fixing that and the amount of > bikeshedding, seeing that the closest cutoff date is actually 31st of > december 2069 in the rtc subsystem and that anyway the current 32bit > userspace will explode in february 2038. > > My plan from the beginning was to have something for the next stable. I > know nobody can read my mind but again, I don't think there is currently > any urgency to change anything. Yes, mind reading is a problem. I can only read minds of ferungulates, and only if they are physicaly near me :-). Best regards, Pavel -- (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. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 18:08 ` Pavel Machek 0 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-21 18:08 UTC (permalink / raw) To: Alexandre Belloni Cc: Thomas Gleixner, Russell King - ARM Linux, Benjamin Gaignard, Baruch Siach, patches, Linus Walleij, linux-tegra, Thierry Reding, x86, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel, Jason Cooper, rtc-linux, linux-pm, Hans Ulli Kroll, adi-buildroot-devel, Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan, linux-arm-kernel, Alessandro Zummo, Barry Song, Support Opensource, netdev, Rafael J. Wysocki, linux-kernel, Steve Twiss, Maxime Ripard [-- Attachment #1: Type: text/plain, Size: 1791 bytes --] Hi! > > > 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. > > > > You can only if your machine is running when that happens. If that is > not the case, then you lost and your time is not correct anymore. I don't see why that should be a case... as long as you know what RTC does in event of overflow, and it is not something completely crazy. > > 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. > > Yes, I'm in the middle of the whole rework that allows that. > > I don't understand the sudden urgency of fixing that and the amount of > bikeshedding, seeing that the closest cutoff date is actually 31st of > december 2069 in the rtc subsystem and that anyway the current 32bit > userspace will explode in february 2038. > > My plan from the beginning was to have something for the next stable. I > know nobody can read my mind but again, I don't think there is currently > any urgency to change anything. Yes, mind reading is a problem. I can only read minds of ferungulates, and only if they are physicaly near me :-). Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions 2017-06-21 8:39 ` Alexandre Belloni (?) (?) @ 2017-06-21 9:19 ` Russell King - ARM Linux -1 siblings, 0 replies; 106+ messages in thread From: Russell King - ARM Linux @ 2017-06-21 9:19 UTC (permalink / raw) To: Alexandre Belloni Cc: Pavel Machek, Thomas Gleixner, Benjamin Gaignard, Baruch Siach, patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E, Linus Walleij, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Thierry Reding, x86-DgEjT+Ai2ygdnm+yROfE0A, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Jason Cooper, rtc-linux On Wed, Jun 21, 2017 at 10:39:07AM +0200, Alexandre Belloni wrote: > On 21/06/2017 at 09:51:52 +0200, Pavel Machek wrote: > > 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. ... and that basically means you can't use hardware that stores RTC time as a 32-bit number of seconds past 2106. > 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. Not for the case being discussed. A 32-bit counter of seconds knows nothing about leap years - all that is handled by the conversion functions. -- 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 9:19 ` Russell King - ARM Linux 0 siblings, 0 replies; 106+ messages in thread From: Russell King - ARM Linux @ 2017-06-21 9:19 UTC (permalink / raw) To: linux-arm-kernel On Wed, Jun 21, 2017 at 10:39:07AM +0200, Alexandre Belloni wrote: > On 21/06/2017 at 09:51:52 +0200, Pavel Machek wrote: > > 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. ... and that basically means you can't use hardware that stores RTC time as a 32-bit number of seconds past 2106. > 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. Not for the case being discussed. A 32-bit counter of seconds knows nothing about leap years - all that is handled by the conversion functions. -- 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 9:19 ` Russell King - ARM Linux 0 siblings, 0 replies; 106+ messages in thread From: Russell King - ARM Linux @ 2017-06-21 9:19 UTC (permalink / raw) To: Alexandre Belloni Cc: Pavel Machek, Thomas Gleixner, Benjamin Gaignard, Baruch Siach, patches, Linus Walleij, linux-tegra, Thierry Reding, x86, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel, Jason Cooper, rtc-linux, linux-pm, Hans Ulli Kroll, adi-buildroot-devel, Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan, linux-arm-kernel, Alessandro Zummo, Barry Song, Support Opensource, netdev, Rafael J. Wysocki, linux-kernel, Steve Twiss, Maxime Ripard On Wed, Jun 21, 2017 at 10:39:07AM +0200, Alexandre Belloni wrote: > On 21/06/2017 at 09:51:52 +0200, Pavel Machek wrote: > > 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. ... and that basically means you can't use hardware that stores RTC time as a 32-bit number of seconds past 2106. > 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. Not for the case being discussed. A 32-bit counter of seconds knows nothing about leap years - all that is handled by the conversion functions. -- 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 9:19 ` Russell King - ARM Linux 0 siblings, 0 replies; 106+ messages in thread From: Russell King - ARM Linux @ 2017-06-21 9:19 UTC (permalink / raw) To: Alexandre Belloni Cc: Pavel Machek, Thomas Gleixner, Benjamin Gaignard, Baruch Siach, patches, Linus Walleij, linux-tegra, Thierry Reding, x86, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel, Jason Cooper, rtc-linux, linux-pm, Hans Ulli Kroll, adi-buildroot-devel, Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan, linux-arm-kernel, Alessandro Zummo, Barry Song, Support Opensource, netdev, Rafael J. Wysocki, linux-kernel, Steve Twiss, Maxime Ripard On Wed, Jun 21, 2017 at 10:39:07AM +0200, Alexandre Belloni wrote: > On 21/06/2017 at 09:51:52 +0200, Pavel Machek wrote: > > 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. ... and that basically means you can't use hardware that stores RTC time as a 32-bit number of seconds past 2106. > 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. Not for the case being discussed. A 32-bit counter of seconds knows nothing about leap years - all that is handled by the conversion functions. -- 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
[parent not found: <20170621091948.GP4902-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>]
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions 2017-06-21 9:19 ` Russell King - ARM Linux ` (2 preceding siblings ...) (?) @ 2017-06-21 9:41 ` Alexandre Belloni -1 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-21 9:41 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Pavel Machek, Thomas Gleixner, Benjamin Gaignard, Baruch Siach, patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E, Linus Walleij, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Thierry Reding, x86-DgEjT+Ai2ygdnm+yROfE0A, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Jason Cooper, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, linux-pm-u79uwXL29TY76Z2rM5mHXA On 21/06/2017 at 10:19:49 +0100, Russell King - ARM Linux wrote: > On Wed, Jun 21, 2017 at 10:39:07AM +0200, Alexandre Belloni wrote: > > On 21/06/2017 at 09:51:52 +0200, Pavel Machek wrote: > > > 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. > > ... and that basically means you can't use hardware that stores RTC > time as a 32-bit number of seconds past 2106. > And I guess it will not matter much for us anyway ;) > > 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. > > Not for the case being discussed. A 32-bit counter of seconds knows > nothing about leap years - all that is handled by the conversion > functions. > Well, the patch series touches some RTCs that are not using 32 bit counter so I though I might as well raise the issue now. -- 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 9:41 ` Alexandre Belloni 0 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-21 9:41 UTC (permalink / raw) To: linux-arm-kernel On 21/06/2017 at 10:19:49 +0100, Russell King - ARM Linux wrote: > On Wed, Jun 21, 2017 at 10:39:07AM +0200, Alexandre Belloni wrote: > > On 21/06/2017 at 09:51:52 +0200, Pavel Machek wrote: > > > 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. > > ... and that basically means you can't use hardware that stores RTC > time as a 32-bit number of seconds past 2106. > And I guess it will not matter much for us anyway ;) > > 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. > > Not for the case being discussed. A 32-bit counter of seconds knows > nothing about leap years - all that is handled by the conversion > functions. > Well, the patch series touches some RTCs that are not using 32 bit counter so I though I might as well raise the issue now. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 9:41 ` Alexandre Belloni 0 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-21 9:41 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Pavel Machek, Thomas Gleixner, Benjamin Gaignard, Baruch Siach, patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E, Linus Walleij, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Thierry Reding, x86-DgEjT+Ai2ygdnm+yROfE0A, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Jason Cooper, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, linux-pm-u79uwXL29TY76Z2rM5mHXA, Hans Ulli Kroll On 21/06/2017 at 10:19:49 +0100, Russell King - ARM Linux wrote: > On Wed, Jun 21, 2017 at 10:39:07AM +0200, Alexandre Belloni wrote: > > On 21/06/2017 at 09:51:52 +0200, Pavel Machek wrote: > > > 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. > > ... and that basically means you can't use hardware that stores RTC > time as a 32-bit number of seconds past 2106. > And I guess it will not matter much for us anyway ;) > > 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. > > Not for the case being discussed. A 32-bit counter of seconds knows > nothing about leap years - all that is handled by the conversion > functions. > Well, the patch series touches some RTCs that are not using 32 bit counter so I though I might as well raise the issue now. -- 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 9:41 ` Alexandre Belloni 0 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-21 9:41 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Pavel Machek, Thomas Gleixner, Benjamin Gaignard, Baruch Siach, patches, Linus Walleij, linux-tegra, Thierry Reding, x86, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel, Jason Cooper, rtc-linux, linux-pm, Hans Ulli Kroll, adi-buildroot-devel, Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan, linux-arm-kernel, Alessandro Zummo, Barry Song, Support Opensource, netdev, Rafael J. Wysocki, linux-kernel, Steve Twiss, Maxime Ripard On 21/06/2017 at 10:19:49 +0100, Russell King - ARM Linux wrote: > On Wed, Jun 21, 2017 at 10:39:07AM +0200, Alexandre Belloni wrote: > > On 21/06/2017 at 09:51:52 +0200, Pavel Machek wrote: > > > 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. > > ... and that basically means you can't use hardware that stores RTC > time as a 32-bit number of seconds past 2106. > And I guess it will not matter much for us anyway ;) > > 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. > > Not for the case being discussed. A 32-bit counter of seconds knows > nothing about leap years - all that is handled by the conversion > functions. > Well, the patch series touches some RTCs that are not using 32 bit counter so I though I might as well raise the issue now. -- 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 9:41 ` Alexandre Belloni 0 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-21 9:41 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Pavel Machek, Thomas Gleixner, Benjamin Gaignard, Baruch Siach, patches, Linus Walleij, linux-tegra, Thierry Reding, x86, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel, Jason Cooper, rtc-linux, linux-pm, Hans Ulli Kroll, adi-buildroot-devel, Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan, linux-arm-kernel, Alessandro Zummo, Barry Song, Support Opensource, netdev, Rafael J. Wysocki, linux-kernel, Steve Twiss, Maxime Ripard On 21/06/2017 at 10:19:49 +0100, Russell King - ARM Linux wrote: > On Wed, Jun 21, 2017 at 10:39:07AM +0200, Alexandre Belloni wrote: > > On 21/06/2017 at 09:51:52 +0200, Pavel Machek wrote: > > > 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. > > ... and that basically means you can't use hardware that stores RTC > time as a 32-bit number of seconds past 2106. > And I guess it will not matter much for us anyway ;) > > 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. > > Not for the case being discussed. A 32-bit counter of seconds knows > nothing about leap years - all that is handled by the conversion > functions. > Well, the patch series touches some RTCs that are not using 32 bit counter so I though I might as well raise the issue now. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 9:35 ` Benjamin Gaignard 0 siblings, 0 replies; 106+ messages in thread From: Benjamin Gaignard @ 2017-06-20 9:35 UTC (permalink / raw) To: benjamin.gaignard-QSEj5FYQhm4dnm+yROfE0A Cc: linaro-kernel-cunTk1MwBs8s++Sfvej+rw, adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Alessandro Zummo, Alexandre Belloni, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Michael Chan, netdev-u79uwXL29TY76Z2rM5mHXA, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, Sebastian Hesselbarth, Support Opensource, Thomas Gleixner, x86-DgEjT+Ai2ygdnm+yROfE0A, Baruch Siach, Hans Ulli Kroll, Vladimir Zapolskiy, Sylvain Lemieux rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they rely on 32bits variables and that will make rtc break in y2038/2016. The goal of this series of patches is ti stop using those two functions and use instead to safer 64bits ones. It also remove change .set_mmss to set_mmss64 callback for the same reasons. Those 51 patches almost clean all the drivers except the few that I haven't been able to compile because of cross-toolchains issues (au1xxx, mpc5121, ps3, puv3, sun4v, tx4939, starfire, ls1x ...) Obviously I don't have all those hardwares in my hands so I have only check that the patches compile without warnings but it up to each maintainer to valid them on real hardware. Benjamin Gaignard (51): x86: rtc: stop using rtc deprecated functions x86: intel-mid: vrtc: stop using rtc deprecated functions net: broadcom: stop using rtc deprecated functions rtc: 88pm80x: stop using rtc deprecated functions rtc: 88pm860x: stop using rtc deprecated functions rtc: ab-b5ze-s3: stop using rtc deprecated functions rtc: ab8500: stop using rtc deprecated functions rtc: armada38x: stop using rtc deprecated functions rtc: at32ap700x: stop using rtc deprecated functions rtc: at91sam9: stop using rtc deprecated functions rtc: bfin: stop using rtc deprecated functions rtc: coh901331: stop using rtc deprecated functions rtc: cpcap: stop using rtc deprecated functions rtc: da9063: stop using rtc deprecated functions rtc: da9063: stop using rtc deprecated functions rtc: davinci: stop using rtc deprecated functions rtc: digicolor: stop using rtc deprecated functions rtc: dm355evm: stop using rtc deprecated functions rtc: ds1305: stop using rtc deprecated functions rtc: ds1374: stop using rtc deprecated functions rtc: ds1511: stop using rtc deprecated functions rtc: ds1553: stop using rtc deprecated functions rtc: ds1672: stop using rtc deprecated functions rtc: ds2404: stop using rtc deprecated functions rtc: ep93xx: stop using rtc deprecated functions rtc: gemini: stop using rtc deprecated functions rtc: imxdi: stop using rtc deprecated functions rtc: jz4740: stop using rtc deprecated functions rtc: lpc32xx: stop using rtc deprecated functions rtc: mv: stop using rtc deprecated functions rtc: omap: stop using rtc deprecated functions rtc: pcap: stop using rtc deprecated functions rtc: pl030: stop using rtc deprecated functions rtc: pl031: stop using rtc deprecated functions rtc: pm8xxx: stop using rtc deprecated functions rtc: rs5c348: stop using rtc deprecated functions rtc: sa1100: stop using rtc deprecated functions rtc: sh: stop using rtc deprecated functions rtc: sirfsoc: stop using rtc deprecated functions rtc: snvs: stop using rtc deprecated functions rtc: stk17ta8: stop using rtc deprecated functions rtc: stmp3xxx: stop using rtc deprecated functions rtc: sun6i: stop using rtc deprecated functions rtc: sysfs: stop using rtc deprecated functions rtc: tegra stop using rtc deprecated functions rtc: test: stop using rtc deprecated functions rtc: tps6586: stop using rtc deprecated functions rtc: vr41xx: stop using rtc deprecated functions rtc: wm831x: stop using rtc deprecated functions rtc: xgene stop using rtc deprecated functions power: suspend test: stop using rtc deprecated functions arch/x86/kernel/rtc.c | 6 ++-- arch/x86/platform/intel-mid/intel_mid_vrtc.c | 2 +- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +- drivers/rtc/rtc-88pm80x.c | 44 +++++++++++++-------------- drivers/rtc/rtc-88pm860x.c | 40 ++++++++++++------------- drivers/rtc/rtc-ab-b5ze-s3.c | 45 ++++++++-------------------- drivers/rtc/rtc-ab8500.c | 26 ++++++++-------- drivers/rtc/rtc-armada38x.c | 34 +++++++++------------ drivers/rtc/rtc-at32ap700x.c | 29 ++++++++---------- drivers/rtc/rtc-at91sam9.c | 18 ++++------- drivers/rtc/rtc-bfin.c | 24 +++++++-------- drivers/rtc/rtc-coh901331.c | 14 +++++---- drivers/rtc/rtc-cpcap.c | 8 ++--- drivers/rtc/rtc-da9052.c | 8 ++--- drivers/rtc/rtc-da9063.c | 8 ++--- drivers/rtc/rtc-davinci.c | 8 ++--- drivers/rtc/rtc-digicolor.c | 4 +-- drivers/rtc/rtc-dm355evm.c | 6 ++-- drivers/rtc/rtc-ds1305.c | 11 +++---- drivers/rtc/rtc-ds1374.c | 6 ++-- drivers/rtc/rtc-ds1511.c | 2 +- drivers/rtc/rtc-ds1553.c | 2 +- drivers/rtc/rtc-ds1672.c | 8 ++--- drivers/rtc/rtc-ds2404.c | 8 ++--- drivers/rtc/rtc-ep93xx.c | 10 +++---- drivers/rtc/rtc-gemini.c | 8 ++--- drivers/rtc/rtc-imxdi.c | 16 +++++----- drivers/rtc/rtc-jz4740.c | 12 ++++---- drivers/rtc/rtc-lpc32xx.c | 19 +++++------- drivers/rtc/rtc-mv.c | 2 +- drivers/rtc/rtc-omap.c | 6 ++-- drivers/rtc/rtc-pcap.c | 16 +++++----- drivers/rtc/rtc-pl030.c | 24 +++++++-------- drivers/rtc/rtc-pl031.c | 31 ++++++++----------- drivers/rtc/rtc-pm8xxx.c | 22 +++++++------- drivers/rtc/rtc-rs5c348.c | 4 +-- drivers/rtc/rtc-sa1100.c | 25 +++++++--------- drivers/rtc/rtc-sh.c | 2 +- drivers/rtc/rtc-sirfsoc.c | 18 +++++------ drivers/rtc/rtc-snvs.c | 14 ++++----- drivers/rtc/rtc-stk17ta8.c | 2 +- drivers/rtc/rtc-stmp3xxx.c | 12 ++++---- drivers/rtc/rtc-sun6i.c | 14 ++++----- drivers/rtc/rtc-sysfs.c | 25 ++++++++-------- drivers/rtc/rtc-tegra.c | 22 +++++++------- drivers/rtc/rtc-test.c | 17 +---------- drivers/rtc/rtc-tps6586x.c | 26 ++++++++-------- drivers/rtc/rtc-vr41xx.c | 6 ++-- drivers/rtc/rtc-wm831x.c | 28 +++++++---------- drivers/rtc/rtc-xgene.c | 12 ++++---- kernel/power/suspend_test.c | 6 ++-- 51 files changed, 342 insertions(+), 420 deletions(-) -- CC: adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org CC: Alessandro Zummo <a.zummo-BfzFCNDTiLLj+vYz1yj4TQ@public.gmane.org> CC: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> CC: Gregory Clement <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> CC: Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> CC: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org> CC: John Stultz <john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> CC: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org CC: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org CC: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> CC: Michael Chan <michael.chan-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> CC: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org CC: rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org CC: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> CC: Support Opensource <support.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org> CC: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org> CC: x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org CC: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> CC: Hans Ulli Kroll <ulli.kroll-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> CC: Vladimir Zapolskiy <vz-ChpfBGZJDbMAvxtiuMwx3w@public.gmane.org> CC: Sylvain Lemieux <slemieux.tyco-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> CC: Barry Song <baohua-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> CC: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> CC: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> CC: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> CC: Jonathan Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> CC: linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org CC: patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org CC: "Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org> CC: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org> CC: Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> CC: linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org 1.9.1 -- 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 9:35 ` Benjamin Gaignard 0 siblings, 0 replies; 106+ messages in thread From: Benjamin Gaignard @ 2017-06-20 9:35 UTC (permalink / raw) To: linux-arm-kernel rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they rely on 32bits variables and that will make rtc break in y2038/2016. The goal of this series of patches is ti stop using those two functions and use instead to safer 64bits ones. It also remove change .set_mmss to set_mmss64 callback for the same reasons. Those 51 patches almost clean all the drivers except the few that I haven't been able to compile because of cross-toolchains issues (au1xxx, mpc5121, ps3, puv3, sun4v, tx4939, starfire, ls1x ...) Obviously I don't have all those hardwares in my hands so I have only check that the patches compile without warnings but it up to each maintainer to valid them on real hardware. Benjamin Gaignard (51): x86: rtc: stop using rtc deprecated functions x86: intel-mid: vrtc: stop using rtc deprecated functions net: broadcom: stop using rtc deprecated functions rtc: 88pm80x: stop using rtc deprecated functions rtc: 88pm860x: stop using rtc deprecated functions rtc: ab-b5ze-s3: stop using rtc deprecated functions rtc: ab8500: stop using rtc deprecated functions rtc: armada38x: stop using rtc deprecated functions rtc: at32ap700x: stop using rtc deprecated functions rtc: at91sam9: stop using rtc deprecated functions rtc: bfin: stop using rtc deprecated functions rtc: coh901331: stop using rtc deprecated functions rtc: cpcap: stop using rtc deprecated functions rtc: da9063: stop using rtc deprecated functions rtc: da9063: stop using rtc deprecated functions rtc: davinci: stop using rtc deprecated functions rtc: digicolor: stop using rtc deprecated functions rtc: dm355evm: stop using rtc deprecated functions rtc: ds1305: stop using rtc deprecated functions rtc: ds1374: stop using rtc deprecated functions rtc: ds1511: stop using rtc deprecated functions rtc: ds1553: stop using rtc deprecated functions rtc: ds1672: stop using rtc deprecated functions rtc: ds2404: stop using rtc deprecated functions rtc: ep93xx: stop using rtc deprecated functions rtc: gemini: stop using rtc deprecated functions rtc: imxdi: stop using rtc deprecated functions rtc: jz4740: stop using rtc deprecated functions rtc: lpc32xx: stop using rtc deprecated functions rtc: mv: stop using rtc deprecated functions rtc: omap: stop using rtc deprecated functions rtc: pcap: stop using rtc deprecated functions rtc: pl030: stop using rtc deprecated functions rtc: pl031: stop using rtc deprecated functions rtc: pm8xxx: stop using rtc deprecated functions rtc: rs5c348: stop using rtc deprecated functions rtc: sa1100: stop using rtc deprecated functions rtc: sh: stop using rtc deprecated functions rtc: sirfsoc: stop using rtc deprecated functions rtc: snvs: stop using rtc deprecated functions rtc: stk17ta8: stop using rtc deprecated functions rtc: stmp3xxx: stop using rtc deprecated functions rtc: sun6i: stop using rtc deprecated functions rtc: sysfs: stop using rtc deprecated functions rtc: tegra stop using rtc deprecated functions rtc: test: stop using rtc deprecated functions rtc: tps6586: stop using rtc deprecated functions rtc: vr41xx: stop using rtc deprecated functions rtc: wm831x: stop using rtc deprecated functions rtc: xgene stop using rtc deprecated functions power: suspend test: stop using rtc deprecated functions arch/x86/kernel/rtc.c | 6 ++-- arch/x86/platform/intel-mid/intel_mid_vrtc.c | 2 +- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +- drivers/rtc/rtc-88pm80x.c | 44 +++++++++++++-------------- drivers/rtc/rtc-88pm860x.c | 40 ++++++++++++------------- drivers/rtc/rtc-ab-b5ze-s3.c | 45 ++++++++-------------------- drivers/rtc/rtc-ab8500.c | 26 ++++++++-------- drivers/rtc/rtc-armada38x.c | 34 +++++++++------------ drivers/rtc/rtc-at32ap700x.c | 29 ++++++++---------- drivers/rtc/rtc-at91sam9.c | 18 ++++------- drivers/rtc/rtc-bfin.c | 24 +++++++-------- drivers/rtc/rtc-coh901331.c | 14 +++++---- drivers/rtc/rtc-cpcap.c | 8 ++--- drivers/rtc/rtc-da9052.c | 8 ++--- drivers/rtc/rtc-da9063.c | 8 ++--- drivers/rtc/rtc-davinci.c | 8 ++--- drivers/rtc/rtc-digicolor.c | 4 +-- drivers/rtc/rtc-dm355evm.c | 6 ++-- drivers/rtc/rtc-ds1305.c | 11 +++---- drivers/rtc/rtc-ds1374.c | 6 ++-- drivers/rtc/rtc-ds1511.c | 2 +- drivers/rtc/rtc-ds1553.c | 2 +- drivers/rtc/rtc-ds1672.c | 8 ++--- drivers/rtc/rtc-ds2404.c | 8 ++--- drivers/rtc/rtc-ep93xx.c | 10 +++---- drivers/rtc/rtc-gemini.c | 8 ++--- drivers/rtc/rtc-imxdi.c | 16 +++++----- drivers/rtc/rtc-jz4740.c | 12 ++++---- drivers/rtc/rtc-lpc32xx.c | 19 +++++------- drivers/rtc/rtc-mv.c | 2 +- drivers/rtc/rtc-omap.c | 6 ++-- drivers/rtc/rtc-pcap.c | 16 +++++----- drivers/rtc/rtc-pl030.c | 24 +++++++-------- drivers/rtc/rtc-pl031.c | 31 ++++++++----------- drivers/rtc/rtc-pm8xxx.c | 22 +++++++------- drivers/rtc/rtc-rs5c348.c | 4 +-- drivers/rtc/rtc-sa1100.c | 25 +++++++--------- drivers/rtc/rtc-sh.c | 2 +- drivers/rtc/rtc-sirfsoc.c | 18 +++++------ drivers/rtc/rtc-snvs.c | 14 ++++----- drivers/rtc/rtc-stk17ta8.c | 2 +- drivers/rtc/rtc-stmp3xxx.c | 12 ++++---- drivers/rtc/rtc-sun6i.c | 14 ++++----- drivers/rtc/rtc-sysfs.c | 25 ++++++++-------- drivers/rtc/rtc-tegra.c | 22 +++++++------- drivers/rtc/rtc-test.c | 17 +---------- drivers/rtc/rtc-tps6586x.c | 26 ++++++++-------- drivers/rtc/rtc-vr41xx.c | 6 ++-- drivers/rtc/rtc-wm831x.c | 28 +++++++---------- drivers/rtc/rtc-xgene.c | 12 ++++---- kernel/power/suspend_test.c | 6 ++-- 51 files changed, 342 insertions(+), 420 deletions(-) -- CC: adi-buildroot-devel at lists.sourceforge.net CC: Alessandro Zummo <a.zummo@towertech.it> CC: Alexandre Belloni <alexandre.belloni@free-electrons.com> CC: Gregory Clement <gregory.clement@free-electrons.com> CC: Ingo Molnar <mingo@redhat.com> CC: Jason Cooper <jason@lakedaemon.net> CC: John Stultz <john.stultz@linaro.org> CC: linux-arm-kernel at lists.infradead.org CC: linux-kernel at vger.kernel.org CC: Linus Walleij <linus.walleij@linaro.org> CC: Michael Chan <michael.chan@broadcom.com> CC: netdev at vger.kernel.org CC: rtc-linux at googlegroups.com CC: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> CC: Support Opensource <support.opensource@diasemi.com> CC: Thomas Gleixner <tglx@linutronix.de> CC: x86 at kernel.org CC: Baruch Siach <baruch@tkos.co.il> CC: Hans Ulli Kroll <ulli.kroll@googlemail.com> CC: Vladimir Zapolskiy <vz@mleia.com> CC: Sylvain Lemieux <slemieux.tyco@gmail.com> CC: Barry Song <baohua@kernel.org> CC: Maxime Ripard <maxime.ripard@free-electrons.com> CC: Chen-Yu Tsai <wens@csie.org> CC: Thierry Reding <thierry.reding@gmail.com> CC: Jonathan Hunter <jonathanh@nvidia.com> CC: linux-tegra at vger.kernel.org CC: patches at opensource.wolfsonmicro.com CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> CC: Pavel Machek <pavel@ucw.cz> CC: Len Brown <len.brown@intel.com> CC: linux-pm at vger.kernel.org 1.9.1 ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 9:35 ` Benjamin Gaignard 0 siblings, 0 replies; 106+ messages in thread From: Benjamin Gaignard @ 2017-06-20 9:35 UTC (permalink / raw) To: benjamin.gaignard-QSEj5FYQhm4dnm+yROfE0A Cc: linaro-kernel-cunTk1MwBs8s++Sfvej+rw, adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Alessandro Zummo, Alexandre Belloni, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Michael Chan, netdev-u79uwXL29TY76Z2rM5mHXA, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, Sebastian Hesselbarth, Support Opensource, Thomas Gleixner, x86-DgEjT+Ai2ygdnm+yROfE0A, Baruch Siach, Hans Ulli Kroll, Vladimir Zapolskiy, Sylvain Lemieux, Barry Song rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they rely on 32bits variables and that will make rtc break in y2038/2016. The goal of this series of patches is ti stop using those two functions and use instead to safer 64bits ones. It also remove change .set_mmss to set_mmss64 callback for the same reasons. Those 51 patches almost clean all the drivers except the few that I haven't been able to compile because of cross-toolchains issues (au1xxx, mpc5121, ps3, puv3, sun4v, tx4939, starfire, ls1x ...) Obviously I don't have all those hardwares in my hands so I have only check that the patches compile without warnings but it up to each maintainer to valid them on real hardware. Benjamin Gaignard (51): x86: rtc: stop using rtc deprecated functions x86: intel-mid: vrtc: stop using rtc deprecated functions net: broadcom: stop using rtc deprecated functions rtc: 88pm80x: stop using rtc deprecated functions rtc: 88pm860x: stop using rtc deprecated functions rtc: ab-b5ze-s3: stop using rtc deprecated functions rtc: ab8500: stop using rtc deprecated functions rtc: armada38x: stop using rtc deprecated functions rtc: at32ap700x: stop using rtc deprecated functions rtc: at91sam9: stop using rtc deprecated functions rtc: bfin: stop using rtc deprecated functions rtc: coh901331: stop using rtc deprecated functions rtc: cpcap: stop using rtc deprecated functions rtc: da9063: stop using rtc deprecated functions rtc: da9063: stop using rtc deprecated functions rtc: davinci: stop using rtc deprecated functions rtc: digicolor: stop using rtc deprecated functions rtc: dm355evm: stop using rtc deprecated functions rtc: ds1305: stop using rtc deprecated functions rtc: ds1374: stop using rtc deprecated functions rtc: ds1511: stop using rtc deprecated functions rtc: ds1553: stop using rtc deprecated functions rtc: ds1672: stop using rtc deprecated functions rtc: ds2404: stop using rtc deprecated functions rtc: ep93xx: stop using rtc deprecated functions rtc: gemini: stop using rtc deprecated functions rtc: imxdi: stop using rtc deprecated functions rtc: jz4740: stop using rtc deprecated functions rtc: lpc32xx: stop using rtc deprecated functions rtc: mv: stop using rtc deprecated functions rtc: omap: stop using rtc deprecated functions rtc: pcap: stop using rtc deprecated functions rtc: pl030: stop using rtc deprecated functions rtc: pl031: stop using rtc deprecated functions rtc: pm8xxx: stop using rtc deprecated functions rtc: rs5c348: stop using rtc deprecated functions rtc: sa1100: stop using rtc deprecated functions rtc: sh: stop using rtc deprecated functions rtc: sirfsoc: stop using rtc deprecated functions rtc: snvs: stop using rtc deprecated functions rtc: stk17ta8: stop using rtc deprecated functions rtc: stmp3xxx: stop using rtc deprecated functions rtc: sun6i: stop using rtc deprecated functions rtc: sysfs: stop using rtc deprecated functions rtc: tegra stop using rtc deprecated functions rtc: test: stop using rtc deprecated functions rtc: tps6586: stop using rtc deprecated functions rtc: vr41xx: stop using rtc deprecated functions rtc: wm831x: stop using rtc deprecated functions rtc: xgene stop using rtc deprecated functions power: suspend test: stop using rtc deprecated functions arch/x86/kernel/rtc.c | 6 ++-- arch/x86/platform/intel-mid/intel_mid_vrtc.c | 2 +- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +- drivers/rtc/rtc-88pm80x.c | 44 +++++++++++++-------------- drivers/rtc/rtc-88pm860x.c | 40 ++++++++++++------------- drivers/rtc/rtc-ab-b5ze-s3.c | 45 ++++++++-------------------- drivers/rtc/rtc-ab8500.c | 26 ++++++++-------- drivers/rtc/rtc-armada38x.c | 34 +++++++++------------ drivers/rtc/rtc-at32ap700x.c | 29 ++++++++---------- drivers/rtc/rtc-at91sam9.c | 18 ++++------- drivers/rtc/rtc-bfin.c | 24 +++++++-------- drivers/rtc/rtc-coh901331.c | 14 +++++---- drivers/rtc/rtc-cpcap.c | 8 ++--- drivers/rtc/rtc-da9052.c | 8 ++--- drivers/rtc/rtc-da9063.c | 8 ++--- drivers/rtc/rtc-davinci.c | 8 ++--- drivers/rtc/rtc-digicolor.c | 4 +-- drivers/rtc/rtc-dm355evm.c | 6 ++-- drivers/rtc/rtc-ds1305.c | 11 +++---- drivers/rtc/rtc-ds1374.c | 6 ++-- drivers/rtc/rtc-ds1511.c | 2 +- drivers/rtc/rtc-ds1553.c | 2 +- drivers/rtc/rtc-ds1672.c | 8 ++--- drivers/rtc/rtc-ds2404.c | 8 ++--- drivers/rtc/rtc-ep93xx.c | 10 +++---- drivers/rtc/rtc-gemini.c | 8 ++--- drivers/rtc/rtc-imxdi.c | 16 +++++----- drivers/rtc/rtc-jz4740.c | 12 ++++---- drivers/rtc/rtc-lpc32xx.c | 19 +++++------- drivers/rtc/rtc-mv.c | 2 +- drivers/rtc/rtc-omap.c | 6 ++-- drivers/rtc/rtc-pcap.c | 16 +++++----- drivers/rtc/rtc-pl030.c | 24 +++++++-------- drivers/rtc/rtc-pl031.c | 31 ++++++++----------- drivers/rtc/rtc-pm8xxx.c | 22 +++++++------- drivers/rtc/rtc-rs5c348.c | 4 +-- drivers/rtc/rtc-sa1100.c | 25 +++++++--------- drivers/rtc/rtc-sh.c | 2 +- drivers/rtc/rtc-sirfsoc.c | 18 +++++------ drivers/rtc/rtc-snvs.c | 14 ++++----- drivers/rtc/rtc-stk17ta8.c | 2 +- drivers/rtc/rtc-stmp3xxx.c | 12 ++++---- drivers/rtc/rtc-sun6i.c | 14 ++++----- drivers/rtc/rtc-sysfs.c | 25 ++++++++-------- drivers/rtc/rtc-tegra.c | 22 +++++++------- drivers/rtc/rtc-test.c | 17 +---------- drivers/rtc/rtc-tps6586x.c | 26 ++++++++-------- drivers/rtc/rtc-vr41xx.c | 6 ++-- drivers/rtc/rtc-wm831x.c | 28 +++++++---------- drivers/rtc/rtc-xgene.c | 12 ++++---- kernel/power/suspend_test.c | 6 ++-- 51 files changed, 342 insertions(+), 420 deletions(-) -- CC: adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org CC: Alessandro Zummo <a.zummo-BfzFCNDTiLLj+vYz1yj4TQ@public.gmane.org> CC: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> CC: Gregory Clement <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> CC: Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> CC: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org> CC: John Stultz <john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> CC: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org CC: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org CC: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> CC: Michael Chan <michael.chan-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> CC: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org CC: rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org CC: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> CC: Support Opensource <support.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org> CC: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org> CC: x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org CC: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> CC: Hans Ulli Kroll <ulli.kroll-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> CC: Vladimir Zapolskiy <vz-ChpfBGZJDbMAvxtiuMwx3w@public.gmane.org> CC: Sylvain Lemieux <slemieux.tyco-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> CC: Barry Song <baohua-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> CC: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> CC: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> CC: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> CC: Jonathan Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> CC: linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org CC: patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org CC: "Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org> CC: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org> CC: Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> CC: linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org 1.9.1 -- 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 9:35 ` Benjamin Gaignard 0 siblings, 0 replies; 106+ messages in thread From: Benjamin Gaignard @ 2017-06-20 9:35 UTC (permalink / raw) To: benjamin.gaignard Cc: linaro-kernel, adi-buildroot-devel, Alessandro Zummo, Alexandre Belloni, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel, linux-kernel, Linus Walleij, Michael Chan, netdev, rtc-linux, Sebastian Hesselbarth, Support Opensource, Thomas Gleixner, x86, Baruch Siach, Hans Ulli Kroll, Vladimir Zapolskiy, Sylvain Lemieux, Barry Song, Maxime Ripard, Chen-Yu Tsai, Thierry Reding, Jonathan Hunter, linux-tegra, patches, Rafael J. Wysocki, Pavel Machek, Len Brown, linux-pm rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they rely on 32bits variables and that will make rtc break in y2038/2016. The goal of this series of patches is ti stop using those two functions and use instead to safer 64bits ones. It also remove change .set_mmss to set_mmss64 callback for the same reasons. Those 51 patches almost clean all the drivers except the few that I haven't been able to compile because of cross-toolchains issues (au1xxx, mpc5121, ps3, puv3, sun4v, tx4939, starfire, ls1x ...) Obviously I don't have all those hardwares in my hands so I have only check that the patches compile without warnings but it up to each maintainer to valid them on real hardware. Benjamin Gaignard (51): x86: rtc: stop using rtc deprecated functions x86: intel-mid: vrtc: stop using rtc deprecated functions net: broadcom: stop using rtc deprecated functions rtc: 88pm80x: stop using rtc deprecated functions rtc: 88pm860x: stop using rtc deprecated functions rtc: ab-b5ze-s3: stop using rtc deprecated functions rtc: ab8500: stop using rtc deprecated functions rtc: armada38x: stop using rtc deprecated functions rtc: at32ap700x: stop using rtc deprecated functions rtc: at91sam9: stop using rtc deprecated functions rtc: bfin: stop using rtc deprecated functions rtc: coh901331: stop using rtc deprecated functions rtc: cpcap: stop using rtc deprecated functions rtc: da9063: stop using rtc deprecated functions rtc: da9063: stop using rtc deprecated functions rtc: davinci: stop using rtc deprecated functions rtc: digicolor: stop using rtc deprecated functions rtc: dm355evm: stop using rtc deprecated functions rtc: ds1305: stop using rtc deprecated functions rtc: ds1374: stop using rtc deprecated functions rtc: ds1511: stop using rtc deprecated functions rtc: ds1553: stop using rtc deprecated functions rtc: ds1672: stop using rtc deprecated functions rtc: ds2404: stop using rtc deprecated functions rtc: ep93xx: stop using rtc deprecated functions rtc: gemini: stop using rtc deprecated functions rtc: imxdi: stop using rtc deprecated functions rtc: jz4740: stop using rtc deprecated functions rtc: lpc32xx: stop using rtc deprecated functions rtc: mv: stop using rtc deprecated functions rtc: omap: stop using rtc deprecated functions rtc: pcap: stop using rtc deprecated functions rtc: pl030: stop using rtc deprecated functions rtc: pl031: stop using rtc deprecated functions rtc: pm8xxx: stop using rtc deprecated functions rtc: rs5c348: stop using rtc deprecated functions rtc: sa1100: stop using rtc deprecated functions rtc: sh: stop using rtc deprecated functions rtc: sirfsoc: stop using rtc deprecated functions rtc: snvs: stop using rtc deprecated functions rtc: stk17ta8: stop using rtc deprecated functions rtc: stmp3xxx: stop using rtc deprecated functions rtc: sun6i: stop using rtc deprecated functions rtc: sysfs: stop using rtc deprecated functions rtc: tegra stop using rtc deprecated functions rtc: test: stop using rtc deprecated functions rtc: tps6586: stop using rtc deprecated functions rtc: vr41xx: stop using rtc deprecated functions rtc: wm831x: stop using rtc deprecated functions rtc: xgene stop using rtc deprecated functions power: suspend test: stop using rtc deprecated functions arch/x86/kernel/rtc.c | 6 ++-- arch/x86/platform/intel-mid/intel_mid_vrtc.c | 2 +- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +- drivers/rtc/rtc-88pm80x.c | 44 +++++++++++++-------------- drivers/rtc/rtc-88pm860x.c | 40 ++++++++++++------------- drivers/rtc/rtc-ab-b5ze-s3.c | 45 ++++++++-------------------- drivers/rtc/rtc-ab8500.c | 26 ++++++++-------- drivers/rtc/rtc-armada38x.c | 34 +++++++++------------ drivers/rtc/rtc-at32ap700x.c | 29 ++++++++---------- drivers/rtc/rtc-at91sam9.c | 18 ++++------- drivers/rtc/rtc-bfin.c | 24 +++++++-------- drivers/rtc/rtc-coh901331.c | 14 +++++---- drivers/rtc/rtc-cpcap.c | 8 ++--- drivers/rtc/rtc-da9052.c | 8 ++--- drivers/rtc/rtc-da9063.c | 8 ++--- drivers/rtc/rtc-davinci.c | 8 ++--- drivers/rtc/rtc-digicolor.c | 4 +-- drivers/rtc/rtc-dm355evm.c | 6 ++-- drivers/rtc/rtc-ds1305.c | 11 +++---- drivers/rtc/rtc-ds1374.c | 6 ++-- drivers/rtc/rtc-ds1511.c | 2 +- drivers/rtc/rtc-ds1553.c | 2 +- drivers/rtc/rtc-ds1672.c | 8 ++--- drivers/rtc/rtc-ds2404.c | 8 ++--- drivers/rtc/rtc-ep93xx.c | 10 +++---- drivers/rtc/rtc-gemini.c | 8 ++--- drivers/rtc/rtc-imxdi.c | 16 +++++----- drivers/rtc/rtc-jz4740.c | 12 ++++---- drivers/rtc/rtc-lpc32xx.c | 19 +++++------- drivers/rtc/rtc-mv.c | 2 +- drivers/rtc/rtc-omap.c | 6 ++-- drivers/rtc/rtc-pcap.c | 16 +++++----- drivers/rtc/rtc-pl030.c | 24 +++++++-------- drivers/rtc/rtc-pl031.c | 31 ++++++++----------- drivers/rtc/rtc-pm8xxx.c | 22 +++++++------- drivers/rtc/rtc-rs5c348.c | 4 +-- drivers/rtc/rtc-sa1100.c | 25 +++++++--------- drivers/rtc/rtc-sh.c | 2 +- drivers/rtc/rtc-sirfsoc.c | 18 +++++------ drivers/rtc/rtc-snvs.c | 14 ++++----- drivers/rtc/rtc-stk17ta8.c | 2 +- drivers/rtc/rtc-stmp3xxx.c | 12 ++++---- drivers/rtc/rtc-sun6i.c | 14 ++++----- drivers/rtc/rtc-sysfs.c | 25 ++++++++-------- drivers/rtc/rtc-tegra.c | 22 +++++++------- drivers/rtc/rtc-test.c | 17 +---------- drivers/rtc/rtc-tps6586x.c | 26 ++++++++-------- drivers/rtc/rtc-vr41xx.c | 6 ++-- drivers/rtc/rtc-wm831x.c | 28 +++++++---------- drivers/rtc/rtc-xgene.c | 12 ++++---- kernel/power/suspend_test.c | 6 ++-- 51 files changed, 342 insertions(+), 420 deletions(-) -- CC: adi-buildroot-devel@lists.sourceforge.net CC: Alessandro Zummo <a.zummo@towertech.it> CC: Alexandre Belloni <alexandre.belloni@free-electrons.com> CC: Gregory Clement <gregory.clement@free-electrons.com> CC: Ingo Molnar <mingo@redhat.com> CC: Jason Cooper <jason@lakedaemon.net> CC: John Stultz <john.stultz@linaro.org> CC: linux-arm-kernel@lists.infradead.org CC: linux-kernel@vger.kernel.org CC: Linus Walleij <linus.walleij@linaro.org> CC: Michael Chan <michael.chan@broadcom.com> CC: netdev@vger.kernel.org CC: rtc-linux@googlegroups.com CC: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> CC: Support Opensource <support.opensource@diasemi.com> CC: Thomas Gleixner <tglx@linutronix.de> CC: x86@kernel.org CC: Baruch Siach <baruch@tkos.co.il> CC: Hans Ulli Kroll <ulli.kroll@googlemail.com> CC: Vladimir Zapolskiy <vz@mleia.com> CC: Sylvain Lemieux <slemieux.tyco@gmail.com> CC: Barry Song <baohua@kernel.org> CC: Maxime Ripard <maxime.ripard@free-electrons.com> CC: Chen-Yu Tsai <wens@csie.org> CC: Thierry Reding <thierry.reding@gmail.com> CC: Jonathan Hunter <jonathanh@nvidia.com> CC: linux-tegra@vger.kernel.org CC: patches@opensource.wolfsonmicro.com CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> CC: Pavel Machek <pavel@ucw.cz> CC: Len Brown <len.brown@intel.com> CC: linux-pm@vger.kernel.org 1.9.1 ^ permalink raw reply [flat|nested] 106+ messages in thread
[parent not found: <1497951359-13334-1-git-send-email-benjamin.gaignard-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions 2017-06-20 9:35 ` Benjamin Gaignard (?) (?) @ 2017-06-20 10:03 ` Alexandre Belloni -1 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-20 10:03 UTC (permalink / raw) To: Benjamin Gaignard Cc: linaro-kernel-cunTk1MwBs8s++Sfvej+rw, adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Michael Chan, netdev-u79uwXL29TY76Z2rM5mHXA, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, Sebastian Hesselbarth, Support Opensource, Thomas Gleixner, x86-DgEjT+Ai2ygdnm+yROfE0A, Baruch Siach, Hans Ulli Kroll, Vladimir Zapolskiy On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > rely on 32bits variables and that will make rtc break in y2038/2016. Please don't, because this hide the fact that the hardware will not handle dates in y2038 anyway and as pointed by Russell a few month ago, rtc_time_to_tm will be able to catch it but the 64 bit version will silently ignore it. > The goal of this series of patches is ti stop using those two functions > and use instead to safer 64bits ones. > > It also remove change .set_mmss to set_mmss64 callback for the same reasons. > > Those 51 patches almost clean all the drivers except the few that I haven't > been able to compile because of cross-toolchains issues (au1xxx, mpc5121, ps3, > puv3, sun4v, tx4939, starfire, ls1x ...) > > Obviously I don't have all those hardwares in my hands so I have only check > that the patches compile without warnings but it up to each maintainer to > valid them on real hardware. > > Benjamin Gaignard (51): > x86: rtc: stop using rtc deprecated functions > x86: intel-mid: vrtc: stop using rtc deprecated functions > net: broadcom: stop using rtc deprecated functions > rtc: 88pm80x: stop using rtc deprecated functions > rtc: 88pm860x: stop using rtc deprecated functions > rtc: ab-b5ze-s3: stop using rtc deprecated functions > rtc: ab8500: stop using rtc deprecated functions > rtc: armada38x: stop using rtc deprecated functions > rtc: at32ap700x: stop using rtc deprecated functions > rtc: at91sam9: stop using rtc deprecated functions > rtc: bfin: stop using rtc deprecated functions > rtc: coh901331: stop using rtc deprecated functions > rtc: cpcap: stop using rtc deprecated functions > rtc: da9063: stop using rtc deprecated functions > rtc: da9063: stop using rtc deprecated functions > rtc: davinci: stop using rtc deprecated functions > rtc: digicolor: stop using rtc deprecated functions > rtc: dm355evm: stop using rtc deprecated functions > rtc: ds1305: stop using rtc deprecated functions > rtc: ds1374: stop using rtc deprecated functions > rtc: ds1511: stop using rtc deprecated functions > rtc: ds1553: stop using rtc deprecated functions > rtc: ds1672: stop using rtc deprecated functions > rtc: ds2404: stop using rtc deprecated functions > rtc: ep93xx: stop using rtc deprecated functions > rtc: gemini: stop using rtc deprecated functions > rtc: imxdi: stop using rtc deprecated functions > rtc: jz4740: stop using rtc deprecated functions > rtc: lpc32xx: stop using rtc deprecated functions > rtc: mv: stop using rtc deprecated functions > rtc: omap: stop using rtc deprecated functions > rtc: pcap: stop using rtc deprecated functions > rtc: pl030: stop using rtc deprecated functions > rtc: pl031: stop using rtc deprecated functions > rtc: pm8xxx: stop using rtc deprecated functions > rtc: rs5c348: stop using rtc deprecated functions > rtc: sa1100: stop using rtc deprecated functions > rtc: sh: stop using rtc deprecated functions > rtc: sirfsoc: stop using rtc deprecated functions > rtc: snvs: stop using rtc deprecated functions > rtc: stk17ta8: stop using rtc deprecated functions > rtc: stmp3xxx: stop using rtc deprecated functions > rtc: sun6i: stop using rtc deprecated functions > rtc: sysfs: stop using rtc deprecated functions > rtc: tegra stop using rtc deprecated functions > rtc: test: stop using rtc deprecated functions > rtc: tps6586: stop using rtc deprecated functions > rtc: vr41xx: stop using rtc deprecated functions > rtc: wm831x: stop using rtc deprecated functions > rtc: xgene stop using rtc deprecated functions > power: suspend test: stop using rtc deprecated functions > > arch/x86/kernel/rtc.c | 6 ++-- > arch/x86/platform/intel-mid/intel_mid_vrtc.c | 2 +- > drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +- > drivers/rtc/rtc-88pm80x.c | 44 +++++++++++++-------------- > drivers/rtc/rtc-88pm860x.c | 40 ++++++++++++------------- > drivers/rtc/rtc-ab-b5ze-s3.c | 45 ++++++++-------------------- > drivers/rtc/rtc-ab8500.c | 26 ++++++++-------- > drivers/rtc/rtc-armada38x.c | 34 +++++++++------------ > drivers/rtc/rtc-at32ap700x.c | 29 ++++++++---------- > drivers/rtc/rtc-at91sam9.c | 18 ++++------- > drivers/rtc/rtc-bfin.c | 24 +++++++-------- > drivers/rtc/rtc-coh901331.c | 14 +++++---- > drivers/rtc/rtc-cpcap.c | 8 ++--- > drivers/rtc/rtc-da9052.c | 8 ++--- > drivers/rtc/rtc-da9063.c | 8 ++--- > drivers/rtc/rtc-davinci.c | 8 ++--- > drivers/rtc/rtc-digicolor.c | 4 +-- > drivers/rtc/rtc-dm355evm.c | 6 ++-- > drivers/rtc/rtc-ds1305.c | 11 +++---- > drivers/rtc/rtc-ds1374.c | 6 ++-- > drivers/rtc/rtc-ds1511.c | 2 +- > drivers/rtc/rtc-ds1553.c | 2 +- > drivers/rtc/rtc-ds1672.c | 8 ++--- > drivers/rtc/rtc-ds2404.c | 8 ++--- > drivers/rtc/rtc-ep93xx.c | 10 +++---- > drivers/rtc/rtc-gemini.c | 8 ++--- > drivers/rtc/rtc-imxdi.c | 16 +++++----- > drivers/rtc/rtc-jz4740.c | 12 ++++---- > drivers/rtc/rtc-lpc32xx.c | 19 +++++------- > drivers/rtc/rtc-mv.c | 2 +- > drivers/rtc/rtc-omap.c | 6 ++-- > drivers/rtc/rtc-pcap.c | 16 +++++----- > drivers/rtc/rtc-pl030.c | 24 +++++++-------- > drivers/rtc/rtc-pl031.c | 31 ++++++++----------- > drivers/rtc/rtc-pm8xxx.c | 22 +++++++------- > drivers/rtc/rtc-rs5c348.c | 4 +-- > drivers/rtc/rtc-sa1100.c | 25 +++++++--------- > drivers/rtc/rtc-sh.c | 2 +- > drivers/rtc/rtc-sirfsoc.c | 18 +++++------ > drivers/rtc/rtc-snvs.c | 14 ++++----- > drivers/rtc/rtc-stk17ta8.c | 2 +- > drivers/rtc/rtc-stmp3xxx.c | 12 ++++---- > drivers/rtc/rtc-sun6i.c | 14 ++++----- > drivers/rtc/rtc-sysfs.c | 25 ++++++++-------- > drivers/rtc/rtc-tegra.c | 22 +++++++------- > drivers/rtc/rtc-test.c | 17 +---------- > drivers/rtc/rtc-tps6586x.c | 26 ++++++++-------- > drivers/rtc/rtc-vr41xx.c | 6 ++-- > drivers/rtc/rtc-wm831x.c | 28 +++++++---------- > drivers/rtc/rtc-xgene.c | 12 ++++---- > kernel/power/suspend_test.c | 6 ++-- > 51 files changed, 342 insertions(+), 420 deletions(-) > > -- > CC: adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > CC: Alessandro Zummo <a.zummo-BfzFCNDTiLLj+vYz1yj4TQ@public.gmane.org> > CC: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> > CC: Gregory Clement <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> > CC: Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > CC: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org> > CC: John Stultz <john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> > CC: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org > CC: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > CC: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> > CC: Michael Chan <michael.chan-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> > CC: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > CC: rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org > CC: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > CC: Support Opensource <support.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org> > CC: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org> > CC: x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org > CC: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> > CC: Hans Ulli Kroll <ulli.kroll-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> > CC: Vladimir Zapolskiy <vz-ChpfBGZJDbMAvxtiuMwx3w@public.gmane.org> > CC: Sylvain Lemieux <slemieux.tyco-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > CC: Barry Song <baohua-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> > CC: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> > CC: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> > CC: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > CC: Jonathan Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> > CC: linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > CC: patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org > CC: "Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org> > CC: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org> > CC: Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> > CC: linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > > 1.9.1 > -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 10:03 ` Alexandre Belloni 0 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-20 10:03 UTC (permalink / raw) To: linux-arm-kernel On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > rely on 32bits variables and that will make rtc break in y2038/2016. Please don't, because this hide the fact that the hardware will not handle dates in y2038 anyway and as pointed by Russell a few month ago, rtc_time_to_tm will be able to catch it but the 64 bit version will silently ignore it. > The goal of this series of patches is ti stop using those two functions > and use instead to safer 64bits ones. > > It also remove change .set_mmss to set_mmss64 callback for the same reasons. > > Those 51 patches almost clean all the drivers except the few that I haven't > been able to compile because of cross-toolchains issues (au1xxx, mpc5121, ps3, > puv3, sun4v, tx4939, starfire, ls1x ...) > > Obviously I don't have all those hardwares in my hands so I have only check > that the patches compile without warnings but it up to each maintainer to > valid them on real hardware. > > Benjamin Gaignard (51): > x86: rtc: stop using rtc deprecated functions > x86: intel-mid: vrtc: stop using rtc deprecated functions > net: broadcom: stop using rtc deprecated functions > rtc: 88pm80x: stop using rtc deprecated functions > rtc: 88pm860x: stop using rtc deprecated functions > rtc: ab-b5ze-s3: stop using rtc deprecated functions > rtc: ab8500: stop using rtc deprecated functions > rtc: armada38x: stop using rtc deprecated functions > rtc: at32ap700x: stop using rtc deprecated functions > rtc: at91sam9: stop using rtc deprecated functions > rtc: bfin: stop using rtc deprecated functions > rtc: coh901331: stop using rtc deprecated functions > rtc: cpcap: stop using rtc deprecated functions > rtc: da9063: stop using rtc deprecated functions > rtc: da9063: stop using rtc deprecated functions > rtc: davinci: stop using rtc deprecated functions > rtc: digicolor: stop using rtc deprecated functions > rtc: dm355evm: stop using rtc deprecated functions > rtc: ds1305: stop using rtc deprecated functions > rtc: ds1374: stop using rtc deprecated functions > rtc: ds1511: stop using rtc deprecated functions > rtc: ds1553: stop using rtc deprecated functions > rtc: ds1672: stop using rtc deprecated functions > rtc: ds2404: stop using rtc deprecated functions > rtc: ep93xx: stop using rtc deprecated functions > rtc: gemini: stop using rtc deprecated functions > rtc: imxdi: stop using rtc deprecated functions > rtc: jz4740: stop using rtc deprecated functions > rtc: lpc32xx: stop using rtc deprecated functions > rtc: mv: stop using rtc deprecated functions > rtc: omap: stop using rtc deprecated functions > rtc: pcap: stop using rtc deprecated functions > rtc: pl030: stop using rtc deprecated functions > rtc: pl031: stop using rtc deprecated functions > rtc: pm8xxx: stop using rtc deprecated functions > rtc: rs5c348: stop using rtc deprecated functions > rtc: sa1100: stop using rtc deprecated functions > rtc: sh: stop using rtc deprecated functions > rtc: sirfsoc: stop using rtc deprecated functions > rtc: snvs: stop using rtc deprecated functions > rtc: stk17ta8: stop using rtc deprecated functions > rtc: stmp3xxx: stop using rtc deprecated functions > rtc: sun6i: stop using rtc deprecated functions > rtc: sysfs: stop using rtc deprecated functions > rtc: tegra stop using rtc deprecated functions > rtc: test: stop using rtc deprecated functions > rtc: tps6586: stop using rtc deprecated functions > rtc: vr41xx: stop using rtc deprecated functions > rtc: wm831x: stop using rtc deprecated functions > rtc: xgene stop using rtc deprecated functions > power: suspend test: stop using rtc deprecated functions > > arch/x86/kernel/rtc.c | 6 ++-- > arch/x86/platform/intel-mid/intel_mid_vrtc.c | 2 +- > drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +- > drivers/rtc/rtc-88pm80x.c | 44 +++++++++++++-------------- > drivers/rtc/rtc-88pm860x.c | 40 ++++++++++++------------- > drivers/rtc/rtc-ab-b5ze-s3.c | 45 ++++++++-------------------- > drivers/rtc/rtc-ab8500.c | 26 ++++++++-------- > drivers/rtc/rtc-armada38x.c | 34 +++++++++------------ > drivers/rtc/rtc-at32ap700x.c | 29 ++++++++---------- > drivers/rtc/rtc-at91sam9.c | 18 ++++------- > drivers/rtc/rtc-bfin.c | 24 +++++++-------- > drivers/rtc/rtc-coh901331.c | 14 +++++---- > drivers/rtc/rtc-cpcap.c | 8 ++--- > drivers/rtc/rtc-da9052.c | 8 ++--- > drivers/rtc/rtc-da9063.c | 8 ++--- > drivers/rtc/rtc-davinci.c | 8 ++--- > drivers/rtc/rtc-digicolor.c | 4 +-- > drivers/rtc/rtc-dm355evm.c | 6 ++-- > drivers/rtc/rtc-ds1305.c | 11 +++---- > drivers/rtc/rtc-ds1374.c | 6 ++-- > drivers/rtc/rtc-ds1511.c | 2 +- > drivers/rtc/rtc-ds1553.c | 2 +- > drivers/rtc/rtc-ds1672.c | 8 ++--- > drivers/rtc/rtc-ds2404.c | 8 ++--- > drivers/rtc/rtc-ep93xx.c | 10 +++---- > drivers/rtc/rtc-gemini.c | 8 ++--- > drivers/rtc/rtc-imxdi.c | 16 +++++----- > drivers/rtc/rtc-jz4740.c | 12 ++++---- > drivers/rtc/rtc-lpc32xx.c | 19 +++++------- > drivers/rtc/rtc-mv.c | 2 +- > drivers/rtc/rtc-omap.c | 6 ++-- > drivers/rtc/rtc-pcap.c | 16 +++++----- > drivers/rtc/rtc-pl030.c | 24 +++++++-------- > drivers/rtc/rtc-pl031.c | 31 ++++++++----------- > drivers/rtc/rtc-pm8xxx.c | 22 +++++++------- > drivers/rtc/rtc-rs5c348.c | 4 +-- > drivers/rtc/rtc-sa1100.c | 25 +++++++--------- > drivers/rtc/rtc-sh.c | 2 +- > drivers/rtc/rtc-sirfsoc.c | 18 +++++------ > drivers/rtc/rtc-snvs.c | 14 ++++----- > drivers/rtc/rtc-stk17ta8.c | 2 +- > drivers/rtc/rtc-stmp3xxx.c | 12 ++++---- > drivers/rtc/rtc-sun6i.c | 14 ++++----- > drivers/rtc/rtc-sysfs.c | 25 ++++++++-------- > drivers/rtc/rtc-tegra.c | 22 +++++++------- > drivers/rtc/rtc-test.c | 17 +---------- > drivers/rtc/rtc-tps6586x.c | 26 ++++++++-------- > drivers/rtc/rtc-vr41xx.c | 6 ++-- > drivers/rtc/rtc-wm831x.c | 28 +++++++---------- > drivers/rtc/rtc-xgene.c | 12 ++++---- > kernel/power/suspend_test.c | 6 ++-- > 51 files changed, 342 insertions(+), 420 deletions(-) > > -- > CC: adi-buildroot-devel at lists.sourceforge.net > CC: Alessandro Zummo <a.zummo@towertech.it> > CC: Alexandre Belloni <alexandre.belloni@free-electrons.com> > CC: Gregory Clement <gregory.clement@free-electrons.com> > CC: Ingo Molnar <mingo@redhat.com> > CC: Jason Cooper <jason@lakedaemon.net> > CC: John Stultz <john.stultz@linaro.org> > CC: linux-arm-kernel at lists.infradead.org > CC: linux-kernel at vger.kernel.org > CC: Linus Walleij <linus.walleij@linaro.org> > CC: Michael Chan <michael.chan@broadcom.com> > CC: netdev at vger.kernel.org > CC: rtc-linux at googlegroups.com > CC: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> > CC: Support Opensource <support.opensource@diasemi.com> > CC: Thomas Gleixner <tglx@linutronix.de> > CC: x86 at kernel.org > CC: Baruch Siach <baruch@tkos.co.il> > CC: Hans Ulli Kroll <ulli.kroll@googlemail.com> > CC: Vladimir Zapolskiy <vz@mleia.com> > CC: Sylvain Lemieux <slemieux.tyco@gmail.com> > CC: Barry Song <baohua@kernel.org> > CC: Maxime Ripard <maxime.ripard@free-electrons.com> > CC: Chen-Yu Tsai <wens@csie.org> > CC: Thierry Reding <thierry.reding@gmail.com> > CC: Jonathan Hunter <jonathanh@nvidia.com> > CC: linux-tegra at vger.kernel.org > CC: patches at opensource.wolfsonmicro.com > CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> > CC: Pavel Machek <pavel@ucw.cz> > CC: Len Brown <len.brown@intel.com> > CC: linux-pm at vger.kernel.org > > 1.9.1 > -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 10:03 ` Alexandre Belloni 0 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-20 10:03 UTC (permalink / raw) To: Benjamin Gaignard Cc: linaro-kernel-cunTk1MwBs8s++Sfvej+rw, adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Michael Chan, netdev-u79uwXL29TY76Z2rM5mHXA, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, Sebastian Hesselbarth, Support Opensource, Thomas Gleixner, x86-DgEjT+Ai2ygdnm+yROfE0A, Baruch Siach, Hans Ulli Kroll, Vladimir Zapolskiy, S On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > rely on 32bits variables and that will make rtc break in y2038/2016. Please don't, because this hide the fact that the hardware will not handle dates in y2038 anyway and as pointed by Russell a few month ago, rtc_time_to_tm will be able to catch it but the 64 bit version will silently ignore it. > The goal of this series of patches is ti stop using those two functions > and use instead to safer 64bits ones. > > It also remove change .set_mmss to set_mmss64 callback for the same reasons. > > Those 51 patches almost clean all the drivers except the few that I haven't > been able to compile because of cross-toolchains issues (au1xxx, mpc5121, ps3, > puv3, sun4v, tx4939, starfire, ls1x ...) > > Obviously I don't have all those hardwares in my hands so I have only check > that the patches compile without warnings but it up to each maintainer to > valid them on real hardware. > > Benjamin Gaignard (51): > x86: rtc: stop using rtc deprecated functions > x86: intel-mid: vrtc: stop using rtc deprecated functions > net: broadcom: stop using rtc deprecated functions > rtc: 88pm80x: stop using rtc deprecated functions > rtc: 88pm860x: stop using rtc deprecated functions > rtc: ab-b5ze-s3: stop using rtc deprecated functions > rtc: ab8500: stop using rtc deprecated functions > rtc: armada38x: stop using rtc deprecated functions > rtc: at32ap700x: stop using rtc deprecated functions > rtc: at91sam9: stop using rtc deprecated functions > rtc: bfin: stop using rtc deprecated functions > rtc: coh901331: stop using rtc deprecated functions > rtc: cpcap: stop using rtc deprecated functions > rtc: da9063: stop using rtc deprecated functions > rtc: da9063: stop using rtc deprecated functions > rtc: davinci: stop using rtc deprecated functions > rtc: digicolor: stop using rtc deprecated functions > rtc: dm355evm: stop using rtc deprecated functions > rtc: ds1305: stop using rtc deprecated functions > rtc: ds1374: stop using rtc deprecated functions > rtc: ds1511: stop using rtc deprecated functions > rtc: ds1553: stop using rtc deprecated functions > rtc: ds1672: stop using rtc deprecated functions > rtc: ds2404: stop using rtc deprecated functions > rtc: ep93xx: stop using rtc deprecated functions > rtc: gemini: stop using rtc deprecated functions > rtc: imxdi: stop using rtc deprecated functions > rtc: jz4740: stop using rtc deprecated functions > rtc: lpc32xx: stop using rtc deprecated functions > rtc: mv: stop using rtc deprecated functions > rtc: omap: stop using rtc deprecated functions > rtc: pcap: stop using rtc deprecated functions > rtc: pl030: stop using rtc deprecated functions > rtc: pl031: stop using rtc deprecated functions > rtc: pm8xxx: stop using rtc deprecated functions > rtc: rs5c348: stop using rtc deprecated functions > rtc: sa1100: stop using rtc deprecated functions > rtc: sh: stop using rtc deprecated functions > rtc: sirfsoc: stop using rtc deprecated functions > rtc: snvs: stop using rtc deprecated functions > rtc: stk17ta8: stop using rtc deprecated functions > rtc: stmp3xxx: stop using rtc deprecated functions > rtc: sun6i: stop using rtc deprecated functions > rtc: sysfs: stop using rtc deprecated functions > rtc: tegra stop using rtc deprecated functions > rtc: test: stop using rtc deprecated functions > rtc: tps6586: stop using rtc deprecated functions > rtc: vr41xx: stop using rtc deprecated functions > rtc: wm831x: stop using rtc deprecated functions > rtc: xgene stop using rtc deprecated functions > power: suspend test: stop using rtc deprecated functions > > arch/x86/kernel/rtc.c | 6 ++-- > arch/x86/platform/intel-mid/intel_mid_vrtc.c | 2 +- > drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +- > drivers/rtc/rtc-88pm80x.c | 44 +++++++++++++-------------- > drivers/rtc/rtc-88pm860x.c | 40 ++++++++++++------------- > drivers/rtc/rtc-ab-b5ze-s3.c | 45 ++++++++-------------------- > drivers/rtc/rtc-ab8500.c | 26 ++++++++-------- > drivers/rtc/rtc-armada38x.c | 34 +++++++++------------ > drivers/rtc/rtc-at32ap700x.c | 29 ++++++++---------- > drivers/rtc/rtc-at91sam9.c | 18 ++++------- > drivers/rtc/rtc-bfin.c | 24 +++++++-------- > drivers/rtc/rtc-coh901331.c | 14 +++++---- > drivers/rtc/rtc-cpcap.c | 8 ++--- > drivers/rtc/rtc-da9052.c | 8 ++--- > drivers/rtc/rtc-da9063.c | 8 ++--- > drivers/rtc/rtc-davinci.c | 8 ++--- > drivers/rtc/rtc-digicolor.c | 4 +-- > drivers/rtc/rtc-dm355evm.c | 6 ++-- > drivers/rtc/rtc-ds1305.c | 11 +++---- > drivers/rtc/rtc-ds1374.c | 6 ++-- > drivers/rtc/rtc-ds1511.c | 2 +- > drivers/rtc/rtc-ds1553.c | 2 +- > drivers/rtc/rtc-ds1672.c | 8 ++--- > drivers/rtc/rtc-ds2404.c | 8 ++--- > drivers/rtc/rtc-ep93xx.c | 10 +++---- > drivers/rtc/rtc-gemini.c | 8 ++--- > drivers/rtc/rtc-imxdi.c | 16 +++++----- > drivers/rtc/rtc-jz4740.c | 12 ++++---- > drivers/rtc/rtc-lpc32xx.c | 19 +++++------- > drivers/rtc/rtc-mv.c | 2 +- > drivers/rtc/rtc-omap.c | 6 ++-- > drivers/rtc/rtc-pcap.c | 16 +++++----- > drivers/rtc/rtc-pl030.c | 24 +++++++-------- > drivers/rtc/rtc-pl031.c | 31 ++++++++----------- > drivers/rtc/rtc-pm8xxx.c | 22 +++++++------- > drivers/rtc/rtc-rs5c348.c | 4 +-- > drivers/rtc/rtc-sa1100.c | 25 +++++++--------- > drivers/rtc/rtc-sh.c | 2 +- > drivers/rtc/rtc-sirfsoc.c | 18 +++++------ > drivers/rtc/rtc-snvs.c | 14 ++++----- > drivers/rtc/rtc-stk17ta8.c | 2 +- > drivers/rtc/rtc-stmp3xxx.c | 12 ++++---- > drivers/rtc/rtc-sun6i.c | 14 ++++----- > drivers/rtc/rtc-sysfs.c | 25 ++++++++-------- > drivers/rtc/rtc-tegra.c | 22 +++++++------- > drivers/rtc/rtc-test.c | 17 +---------- > drivers/rtc/rtc-tps6586x.c | 26 ++++++++-------- > drivers/rtc/rtc-vr41xx.c | 6 ++-- > drivers/rtc/rtc-wm831x.c | 28 +++++++---------- > drivers/rtc/rtc-xgene.c | 12 ++++---- > kernel/power/suspend_test.c | 6 ++-- > 51 files changed, 342 insertions(+), 420 deletions(-) > > -- > CC: adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > CC: Alessandro Zummo <a.zummo-BfzFCNDTiLLj+vYz1yj4TQ@public.gmane.org> > CC: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> > CC: Gregory Clement <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> > CC: Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > CC: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org> > CC: John Stultz <john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> > CC: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org > CC: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > CC: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> > CC: Michael Chan <michael.chan-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> > CC: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > CC: rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org > CC: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > CC: Support Opensource <support.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org> > CC: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org> > CC: x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org > CC: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> > CC: Hans Ulli Kroll <ulli.kroll-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> > CC: Vladimir Zapolskiy <vz-ChpfBGZJDbMAvxtiuMwx3w@public.gmane.org> > CC: Sylvain Lemieux <slemieux.tyco-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > CC: Barry Song <baohua-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> > CC: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> > CC: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> > CC: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > CC: Jonathan Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> > CC: linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > CC: patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org > CC: "Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org> > CC: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org> > CC: Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> > CC: linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > > 1.9.1 > -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 10:03 ` Alexandre Belloni 0 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-20 10:03 UTC (permalink / raw) To: Benjamin Gaignard Cc: linaro-kernel, adi-buildroot-devel, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel, linux-kernel, Linus Walleij, Michael Chan, netdev, rtc-linux, Sebastian Hesselbarth, Support Opensource, Thomas Gleixner, x86, Baruch Siach, Hans Ulli Kroll, Vladimir Zapolskiy, Sylvain Lemieux, Barry Song, Maxime Ripard, Chen-Yu Tsai, Thierry Reding, Jonathan Hunter, linux-tegra, patches, Rafael J. Wysocki, Pavel Machek, Len Brown, linux-pm On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > rely on 32bits variables and that will make rtc break in y2038/2016. Please don't, because this hide the fact that the hardware will not handle dates in y2038 anyway and as pointed by Russell a few month ago, rtc_time_to_tm will be able to catch it but the 64 bit version will silently ignore it. > The goal of this series of patches is ti stop using those two functions > and use instead to safer 64bits ones. > > It also remove change .set_mmss to set_mmss64 callback for the same reasons. > > Those 51 patches almost clean all the drivers except the few that I haven't > been able to compile because of cross-toolchains issues (au1xxx, mpc5121, ps3, > puv3, sun4v, tx4939, starfire, ls1x ...) > > Obviously I don't have all those hardwares in my hands so I have only check > that the patches compile without warnings but it up to each maintainer to > valid them on real hardware. > > Benjamin Gaignard (51): > x86: rtc: stop using rtc deprecated functions > x86: intel-mid: vrtc: stop using rtc deprecated functions > net: broadcom: stop using rtc deprecated functions > rtc: 88pm80x: stop using rtc deprecated functions > rtc: 88pm860x: stop using rtc deprecated functions > rtc: ab-b5ze-s3: stop using rtc deprecated functions > rtc: ab8500: stop using rtc deprecated functions > rtc: armada38x: stop using rtc deprecated functions > rtc: at32ap700x: stop using rtc deprecated functions > rtc: at91sam9: stop using rtc deprecated functions > rtc: bfin: stop using rtc deprecated functions > rtc: coh901331: stop using rtc deprecated functions > rtc: cpcap: stop using rtc deprecated functions > rtc: da9063: stop using rtc deprecated functions > rtc: da9063: stop using rtc deprecated functions > rtc: davinci: stop using rtc deprecated functions > rtc: digicolor: stop using rtc deprecated functions > rtc: dm355evm: stop using rtc deprecated functions > rtc: ds1305: stop using rtc deprecated functions > rtc: ds1374: stop using rtc deprecated functions > rtc: ds1511: stop using rtc deprecated functions > rtc: ds1553: stop using rtc deprecated functions > rtc: ds1672: stop using rtc deprecated functions > rtc: ds2404: stop using rtc deprecated functions > rtc: ep93xx: stop using rtc deprecated functions > rtc: gemini: stop using rtc deprecated functions > rtc: imxdi: stop using rtc deprecated functions > rtc: jz4740: stop using rtc deprecated functions > rtc: lpc32xx: stop using rtc deprecated functions > rtc: mv: stop using rtc deprecated functions > rtc: omap: stop using rtc deprecated functions > rtc: pcap: stop using rtc deprecated functions > rtc: pl030: stop using rtc deprecated functions > rtc: pl031: stop using rtc deprecated functions > rtc: pm8xxx: stop using rtc deprecated functions > rtc: rs5c348: stop using rtc deprecated functions > rtc: sa1100: stop using rtc deprecated functions > rtc: sh: stop using rtc deprecated functions > rtc: sirfsoc: stop using rtc deprecated functions > rtc: snvs: stop using rtc deprecated functions > rtc: stk17ta8: stop using rtc deprecated functions > rtc: stmp3xxx: stop using rtc deprecated functions > rtc: sun6i: stop using rtc deprecated functions > rtc: sysfs: stop using rtc deprecated functions > rtc: tegra stop using rtc deprecated functions > rtc: test: stop using rtc deprecated functions > rtc: tps6586: stop using rtc deprecated functions > rtc: vr41xx: stop using rtc deprecated functions > rtc: wm831x: stop using rtc deprecated functions > rtc: xgene stop using rtc deprecated functions > power: suspend test: stop using rtc deprecated functions > > arch/x86/kernel/rtc.c | 6 ++-- > arch/x86/platform/intel-mid/intel_mid_vrtc.c | 2 +- > drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +- > drivers/rtc/rtc-88pm80x.c | 44 +++++++++++++-------------- > drivers/rtc/rtc-88pm860x.c | 40 ++++++++++++------------- > drivers/rtc/rtc-ab-b5ze-s3.c | 45 ++++++++-------------------- > drivers/rtc/rtc-ab8500.c | 26 ++++++++-------- > drivers/rtc/rtc-armada38x.c | 34 +++++++++------------ > drivers/rtc/rtc-at32ap700x.c | 29 ++++++++---------- > drivers/rtc/rtc-at91sam9.c | 18 ++++------- > drivers/rtc/rtc-bfin.c | 24 +++++++-------- > drivers/rtc/rtc-coh901331.c | 14 +++++---- > drivers/rtc/rtc-cpcap.c | 8 ++--- > drivers/rtc/rtc-da9052.c | 8 ++--- > drivers/rtc/rtc-da9063.c | 8 ++--- > drivers/rtc/rtc-davinci.c | 8 ++--- > drivers/rtc/rtc-digicolor.c | 4 +-- > drivers/rtc/rtc-dm355evm.c | 6 ++-- > drivers/rtc/rtc-ds1305.c | 11 +++---- > drivers/rtc/rtc-ds1374.c | 6 ++-- > drivers/rtc/rtc-ds1511.c | 2 +- > drivers/rtc/rtc-ds1553.c | 2 +- > drivers/rtc/rtc-ds1672.c | 8 ++--- > drivers/rtc/rtc-ds2404.c | 8 ++--- > drivers/rtc/rtc-ep93xx.c | 10 +++---- > drivers/rtc/rtc-gemini.c | 8 ++--- > drivers/rtc/rtc-imxdi.c | 16 +++++----- > drivers/rtc/rtc-jz4740.c | 12 ++++---- > drivers/rtc/rtc-lpc32xx.c | 19 +++++------- > drivers/rtc/rtc-mv.c | 2 +- > drivers/rtc/rtc-omap.c | 6 ++-- > drivers/rtc/rtc-pcap.c | 16 +++++----- > drivers/rtc/rtc-pl030.c | 24 +++++++-------- > drivers/rtc/rtc-pl031.c | 31 ++++++++----------- > drivers/rtc/rtc-pm8xxx.c | 22 +++++++------- > drivers/rtc/rtc-rs5c348.c | 4 +-- > drivers/rtc/rtc-sa1100.c | 25 +++++++--------- > drivers/rtc/rtc-sh.c | 2 +- > drivers/rtc/rtc-sirfsoc.c | 18 +++++------ > drivers/rtc/rtc-snvs.c | 14 ++++----- > drivers/rtc/rtc-stk17ta8.c | 2 +- > drivers/rtc/rtc-stmp3xxx.c | 12 ++++---- > drivers/rtc/rtc-sun6i.c | 14 ++++----- > drivers/rtc/rtc-sysfs.c | 25 ++++++++-------- > drivers/rtc/rtc-tegra.c | 22 +++++++------- > drivers/rtc/rtc-test.c | 17 +---------- > drivers/rtc/rtc-tps6586x.c | 26 ++++++++-------- > drivers/rtc/rtc-vr41xx.c | 6 ++-- > drivers/rtc/rtc-wm831x.c | 28 +++++++---------- > drivers/rtc/rtc-xgene.c | 12 ++++---- > kernel/power/suspend_test.c | 6 ++-- > 51 files changed, 342 insertions(+), 420 deletions(-) > > -- > CC: adi-buildroot-devel@lists.sourceforge.net > CC: Alessandro Zummo <a.zummo@towertech.it> > CC: Alexandre Belloni <alexandre.belloni@free-electrons.com> > CC: Gregory Clement <gregory.clement@free-electrons.com> > CC: Ingo Molnar <mingo@redhat.com> > CC: Jason Cooper <jason@lakedaemon.net> > CC: John Stultz <john.stultz@linaro.org> > CC: linux-arm-kernel@lists.infradead.org > CC: linux-kernel@vger.kernel.org > CC: Linus Walleij <linus.walleij@linaro.org> > CC: Michael Chan <michael.chan@broadcom.com> > CC: netdev@vger.kernel.org > CC: rtc-linux@googlegroups.com > CC: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> > CC: Support Opensource <support.opensource@diasemi.com> > CC: Thomas Gleixner <tglx@linutronix.de> > CC: x86@kernel.org > CC: Baruch Siach <baruch@tkos.co.il> > CC: Hans Ulli Kroll <ulli.kroll@googlemail.com> > CC: Vladimir Zapolskiy <vz@mleia.com> > CC: Sylvain Lemieux <slemieux.tyco@gmail.com> > CC: Barry Song <baohua@kernel.org> > CC: Maxime Ripard <maxime.ripard@free-electrons.com> > CC: Chen-Yu Tsai <wens@csie.org> > CC: Thierry Reding <thierry.reding@gmail.com> > CC: Jonathan Hunter <jonathanh@nvidia.com> > CC: linux-tegra@vger.kernel.org > CC: patches@opensource.wolfsonmicro.com > CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> > CC: Pavel Machek <pavel@ucw.cz> > CC: Len Brown <len.brown@intel.com> > CC: linux-pm@vger.kernel.org > > 1.9.1 > -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 106+ messages in thread
[parent not found: <20170620100348.zh4ygvjjgnhxvmvl-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org>]
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions 2017-06-20 10:03 ` Alexandre Belloni (?) (?) @ 2017-06-20 10:07 ` Alexandre Belloni -1 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-20 10:07 UTC (permalink / raw) To: Benjamin Gaignard Cc: linaro-kernel-cunTk1MwBs8s++Sfvej+rw, adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Michael Chan, netdev-u79uwXL29TY76Z2rM5mHXA, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, Sebastian Hesselbarth, Support Opensource, Thomas Gleixner, x86-DgEjT+Ai2ygdnm+yROfE0A, Baruch Siach, Hans Ulli Kroll, Vladimir Zapolskiy, Sylvain Lemieux, Barry Song, Maxime Ripard On 20/06/2017 at 12:03:48 +0200, Alexandre Belloni wrote: > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > rely on 32bits variables and that will make rtc break in y2038/2016. > > Please don't, because this hide the fact that the hardware will not > handle dates in y2038 anyway and as pointed by Russell a few month ago, > rtc_time_to_tm will be able to catch it but the 64 bit version will > silently ignore it. > Just to be clear, it is fine on your ST hardware because it uses a 64bit counter. Most of the one you patched are using 32 bit counters and so will break anyway. > > > The goal of this series of patches is ti stop using those two functions > > and use instead to safer 64bits ones. > > > > It also remove change .set_mmss to set_mmss64 callback for the same reasons. > > > > Those 51 patches almost clean all the drivers except the few that I haven't > > been able to compile because of cross-toolchains issues (au1xxx, mpc5121, ps3, > > puv3, sun4v, tx4939, starfire, ls1x ...) > > > > Obviously I don't have all those hardwares in my hands so I have only check > > that the patches compile without warnings but it up to each maintainer to > > valid them on real hardware. > > > > Benjamin Gaignard (51): > > x86: rtc: stop using rtc deprecated functions > > x86: intel-mid: vrtc: stop using rtc deprecated functions > > net: broadcom: stop using rtc deprecated functions > > rtc: 88pm80x: stop using rtc deprecated functions > > rtc: 88pm860x: stop using rtc deprecated functions > > rtc: ab-b5ze-s3: stop using rtc deprecated functions > > rtc: ab8500: stop using rtc deprecated functions > > rtc: armada38x: stop using rtc deprecated functions > > rtc: at32ap700x: stop using rtc deprecated functions > > rtc: at91sam9: stop using rtc deprecated functions > > rtc: bfin: stop using rtc deprecated functions > > rtc: coh901331: stop using rtc deprecated functions > > rtc: cpcap: stop using rtc deprecated functions > > rtc: da9063: stop using rtc deprecated functions > > rtc: da9063: stop using rtc deprecated functions > > rtc: davinci: stop using rtc deprecated functions > > rtc: digicolor: stop using rtc deprecated functions > > rtc: dm355evm: stop using rtc deprecated functions > > rtc: ds1305: stop using rtc deprecated functions > > rtc: ds1374: stop using rtc deprecated functions > > rtc: ds1511: stop using rtc deprecated functions > > rtc: ds1553: stop using rtc deprecated functions > > rtc: ds1672: stop using rtc deprecated functions > > rtc: ds2404: stop using rtc deprecated functions > > rtc: ep93xx: stop using rtc deprecated functions > > rtc: gemini: stop using rtc deprecated functions > > rtc: imxdi: stop using rtc deprecated functions > > rtc: jz4740: stop using rtc deprecated functions > > rtc: lpc32xx: stop using rtc deprecated functions > > rtc: mv: stop using rtc deprecated functions > > rtc: omap: stop using rtc deprecated functions > > rtc: pcap: stop using rtc deprecated functions > > rtc: pl030: stop using rtc deprecated functions > > rtc: pl031: stop using rtc deprecated functions > > rtc: pm8xxx: stop using rtc deprecated functions > > rtc: rs5c348: stop using rtc deprecated functions > > rtc: sa1100: stop using rtc deprecated functions > > rtc: sh: stop using rtc deprecated functions > > rtc: sirfsoc: stop using rtc deprecated functions > > rtc: snvs: stop using rtc deprecated functions > > rtc: stk17ta8: stop using rtc deprecated functions > > rtc: stmp3xxx: stop using rtc deprecated functions > > rtc: sun6i: stop using rtc deprecated functions > > rtc: sysfs: stop using rtc deprecated functions > > rtc: tegra stop using rtc deprecated functions > > rtc: test: stop using rtc deprecated functions > > rtc: tps6586: stop using rtc deprecated functions > > rtc: vr41xx: stop using rtc deprecated functions > > rtc: wm831x: stop using rtc deprecated functions > > rtc: xgene stop using rtc deprecated functions > > power: suspend test: stop using rtc deprecated functions > > > > arch/x86/kernel/rtc.c | 6 ++-- > > arch/x86/platform/intel-mid/intel_mid_vrtc.c | 2 +- > > drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +- > > drivers/rtc/rtc-88pm80x.c | 44 +++++++++++++-------------- > > drivers/rtc/rtc-88pm860x.c | 40 ++++++++++++------------- > > drivers/rtc/rtc-ab-b5ze-s3.c | 45 ++++++++-------------------- > > drivers/rtc/rtc-ab8500.c | 26 ++++++++-------- > > drivers/rtc/rtc-armada38x.c | 34 +++++++++------------ > > drivers/rtc/rtc-at32ap700x.c | 29 ++++++++---------- > > drivers/rtc/rtc-at91sam9.c | 18 ++++------- > > drivers/rtc/rtc-bfin.c | 24 +++++++-------- > > drivers/rtc/rtc-coh901331.c | 14 +++++---- > > drivers/rtc/rtc-cpcap.c | 8 ++--- > > drivers/rtc/rtc-da9052.c | 8 ++--- > > drivers/rtc/rtc-da9063.c | 8 ++--- > > drivers/rtc/rtc-davinci.c | 8 ++--- > > drivers/rtc/rtc-digicolor.c | 4 +-- > > drivers/rtc/rtc-dm355evm.c | 6 ++-- > > drivers/rtc/rtc-ds1305.c | 11 +++---- > > drivers/rtc/rtc-ds1374.c | 6 ++-- > > drivers/rtc/rtc-ds1511.c | 2 +- > > drivers/rtc/rtc-ds1553.c | 2 +- > > drivers/rtc/rtc-ds1672.c | 8 ++--- > > drivers/rtc/rtc-ds2404.c | 8 ++--- > > drivers/rtc/rtc-ep93xx.c | 10 +++---- > > drivers/rtc/rtc-gemini.c | 8 ++--- > > drivers/rtc/rtc-imxdi.c | 16 +++++----- > > drivers/rtc/rtc-jz4740.c | 12 ++++---- > > drivers/rtc/rtc-lpc32xx.c | 19 +++++------- > > drivers/rtc/rtc-mv.c | 2 +- > > drivers/rtc/rtc-omap.c | 6 ++-- > > drivers/rtc/rtc-pcap.c | 16 +++++----- > > drivers/rtc/rtc-pl030.c | 24 +++++++-------- > > drivers/rtc/rtc-pl031.c | 31 ++++++++----------- > > drivers/rtc/rtc-pm8xxx.c | 22 +++++++------- > > drivers/rtc/rtc-rs5c348.c | 4 +-- > > drivers/rtc/rtc-sa1100.c | 25 +++++++--------- > > drivers/rtc/rtc-sh.c | 2 +- > > drivers/rtc/rtc-sirfsoc.c | 18 +++++------ > > drivers/rtc/rtc-snvs.c | 14 ++++----- > > drivers/rtc/rtc-stk17ta8.c | 2 +- > > drivers/rtc/rtc-stmp3xxx.c | 12 ++++---- > > drivers/rtc/rtc-sun6i.c | 14 ++++----- > > drivers/rtc/rtc-sysfs.c | 25 ++++++++-------- > > drivers/rtc/rtc-tegra.c | 22 +++++++------- > > drivers/rtc/rtc-test.c | 17 +---------- > > drivers/rtc/rtc-tps6586x.c | 26 ++++++++-------- > > drivers/rtc/rtc-vr41xx.c | 6 ++-- > > drivers/rtc/rtc-wm831x.c | 28 +++++++---------- > > drivers/rtc/rtc-xgene.c | 12 ++++---- > > kernel/power/suspend_test.c | 6 ++-- > > 51 files changed, 342 insertions(+), 420 deletions(-) > > > > -- > > CC: adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > > CC: Alessandro Zummo <a.zummo-BfzFCNDTiLLj+vYz1yj4TQ@public.gmane.org> > > CC: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> > > CC: Gregory Clement <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> > > CC: Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > > CC: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org> > > CC: John Stultz <john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> > > CC: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org > > CC: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > > CC: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> > > CC: Michael Chan <michael.chan-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> > > CC: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > > CC: rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org > > CC: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > CC: Support Opensource <support.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org> > > CC: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org> > > CC: x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org > > CC: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> > > CC: Hans Ulli Kroll <ulli.kroll-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> > > CC: Vladimir Zapolskiy <vz-ChpfBGZJDbMAvxtiuMwx3w@public.gmane.org> > > CC: Sylvain Lemieux <slemieux.tyco-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > CC: Barry Song <baohua-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> > > CC: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> > > CC: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> > > CC: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > CC: Jonathan Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> > > CC: linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > > CC: patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org > > CC: "Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org> > > CC: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org> > > CC: Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> > > CC: linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > > > > 1.9.1 > > > > -- > Alexandre Belloni, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com -- 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 10:07 ` Alexandre Belloni 0 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-20 10:07 UTC (permalink / raw) To: linux-arm-kernel On 20/06/2017 at 12:03:48 +0200, Alexandre Belloni wrote: > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > rely on 32bits variables and that will make rtc break in y2038/2016. > > Please don't, because this hide the fact that the hardware will not > handle dates in y2038 anyway and as pointed by Russell a few month ago, > rtc_time_to_tm will be able to catch it but the 64 bit version will > silently ignore it. > Just to be clear, it is fine on your ST hardware because it uses a 64bit counter. Most of the one you patched are using 32 bit counters and so will break anyway. > > > The goal of this series of patches is ti stop using those two functions > > and use instead to safer 64bits ones. > > > > It also remove change .set_mmss to set_mmss64 callback for the same reasons. > > > > Those 51 patches almost clean all the drivers except the few that I haven't > > been able to compile because of cross-toolchains issues (au1xxx, mpc5121, ps3, > > puv3, sun4v, tx4939, starfire, ls1x ...) > > > > Obviously I don't have all those hardwares in my hands so I have only check > > that the patches compile without warnings but it up to each maintainer to > > valid them on real hardware. > > > > Benjamin Gaignard (51): > > x86: rtc: stop using rtc deprecated functions > > x86: intel-mid: vrtc: stop using rtc deprecated functions > > net: broadcom: stop using rtc deprecated functions > > rtc: 88pm80x: stop using rtc deprecated functions > > rtc: 88pm860x: stop using rtc deprecated functions > > rtc: ab-b5ze-s3: stop using rtc deprecated functions > > rtc: ab8500: stop using rtc deprecated functions > > rtc: armada38x: stop using rtc deprecated functions > > rtc: at32ap700x: stop using rtc deprecated functions > > rtc: at91sam9: stop using rtc deprecated functions > > rtc: bfin: stop using rtc deprecated functions > > rtc: coh901331: stop using rtc deprecated functions > > rtc: cpcap: stop using rtc deprecated functions > > rtc: da9063: stop using rtc deprecated functions > > rtc: da9063: stop using rtc deprecated functions > > rtc: davinci: stop using rtc deprecated functions > > rtc: digicolor: stop using rtc deprecated functions > > rtc: dm355evm: stop using rtc deprecated functions > > rtc: ds1305: stop using rtc deprecated functions > > rtc: ds1374: stop using rtc deprecated functions > > rtc: ds1511: stop using rtc deprecated functions > > rtc: ds1553: stop using rtc deprecated functions > > rtc: ds1672: stop using rtc deprecated functions > > rtc: ds2404: stop using rtc deprecated functions > > rtc: ep93xx: stop using rtc deprecated functions > > rtc: gemini: stop using rtc deprecated functions > > rtc: imxdi: stop using rtc deprecated functions > > rtc: jz4740: stop using rtc deprecated functions > > rtc: lpc32xx: stop using rtc deprecated functions > > rtc: mv: stop using rtc deprecated functions > > rtc: omap: stop using rtc deprecated functions > > rtc: pcap: stop using rtc deprecated functions > > rtc: pl030: stop using rtc deprecated functions > > rtc: pl031: stop using rtc deprecated functions > > rtc: pm8xxx: stop using rtc deprecated functions > > rtc: rs5c348: stop using rtc deprecated functions > > rtc: sa1100: stop using rtc deprecated functions > > rtc: sh: stop using rtc deprecated functions > > rtc: sirfsoc: stop using rtc deprecated functions > > rtc: snvs: stop using rtc deprecated functions > > rtc: stk17ta8: stop using rtc deprecated functions > > rtc: stmp3xxx: stop using rtc deprecated functions > > rtc: sun6i: stop using rtc deprecated functions > > rtc: sysfs: stop using rtc deprecated functions > > rtc: tegra stop using rtc deprecated functions > > rtc: test: stop using rtc deprecated functions > > rtc: tps6586: stop using rtc deprecated functions > > rtc: vr41xx: stop using rtc deprecated functions > > rtc: wm831x: stop using rtc deprecated functions > > rtc: xgene stop using rtc deprecated functions > > power: suspend test: stop using rtc deprecated functions > > > > arch/x86/kernel/rtc.c | 6 ++-- > > arch/x86/platform/intel-mid/intel_mid_vrtc.c | 2 +- > > drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +- > > drivers/rtc/rtc-88pm80x.c | 44 +++++++++++++-------------- > > drivers/rtc/rtc-88pm860x.c | 40 ++++++++++++------------- > > drivers/rtc/rtc-ab-b5ze-s3.c | 45 ++++++++-------------------- > > drivers/rtc/rtc-ab8500.c | 26 ++++++++-------- > > drivers/rtc/rtc-armada38x.c | 34 +++++++++------------ > > drivers/rtc/rtc-at32ap700x.c | 29 ++++++++---------- > > drivers/rtc/rtc-at91sam9.c | 18 ++++------- > > drivers/rtc/rtc-bfin.c | 24 +++++++-------- > > drivers/rtc/rtc-coh901331.c | 14 +++++---- > > drivers/rtc/rtc-cpcap.c | 8 ++--- > > drivers/rtc/rtc-da9052.c | 8 ++--- > > drivers/rtc/rtc-da9063.c | 8 ++--- > > drivers/rtc/rtc-davinci.c | 8 ++--- > > drivers/rtc/rtc-digicolor.c | 4 +-- > > drivers/rtc/rtc-dm355evm.c | 6 ++-- > > drivers/rtc/rtc-ds1305.c | 11 +++---- > > drivers/rtc/rtc-ds1374.c | 6 ++-- > > drivers/rtc/rtc-ds1511.c | 2 +- > > drivers/rtc/rtc-ds1553.c | 2 +- > > drivers/rtc/rtc-ds1672.c | 8 ++--- > > drivers/rtc/rtc-ds2404.c | 8 ++--- > > drivers/rtc/rtc-ep93xx.c | 10 +++---- > > drivers/rtc/rtc-gemini.c | 8 ++--- > > drivers/rtc/rtc-imxdi.c | 16 +++++----- > > drivers/rtc/rtc-jz4740.c | 12 ++++---- > > drivers/rtc/rtc-lpc32xx.c | 19 +++++------- > > drivers/rtc/rtc-mv.c | 2 +- > > drivers/rtc/rtc-omap.c | 6 ++-- > > drivers/rtc/rtc-pcap.c | 16 +++++----- > > drivers/rtc/rtc-pl030.c | 24 +++++++-------- > > drivers/rtc/rtc-pl031.c | 31 ++++++++----------- > > drivers/rtc/rtc-pm8xxx.c | 22 +++++++------- > > drivers/rtc/rtc-rs5c348.c | 4 +-- > > drivers/rtc/rtc-sa1100.c | 25 +++++++--------- > > drivers/rtc/rtc-sh.c | 2 +- > > drivers/rtc/rtc-sirfsoc.c | 18 +++++------ > > drivers/rtc/rtc-snvs.c | 14 ++++----- > > drivers/rtc/rtc-stk17ta8.c | 2 +- > > drivers/rtc/rtc-stmp3xxx.c | 12 ++++---- > > drivers/rtc/rtc-sun6i.c | 14 ++++----- > > drivers/rtc/rtc-sysfs.c | 25 ++++++++-------- > > drivers/rtc/rtc-tegra.c | 22 +++++++------- > > drivers/rtc/rtc-test.c | 17 +---------- > > drivers/rtc/rtc-tps6586x.c | 26 ++++++++-------- > > drivers/rtc/rtc-vr41xx.c | 6 ++-- > > drivers/rtc/rtc-wm831x.c | 28 +++++++---------- > > drivers/rtc/rtc-xgene.c | 12 ++++---- > > kernel/power/suspend_test.c | 6 ++-- > > 51 files changed, 342 insertions(+), 420 deletions(-) > > > > -- > > CC: adi-buildroot-devel at lists.sourceforge.net > > CC: Alessandro Zummo <a.zummo@towertech.it> > > CC: Alexandre Belloni <alexandre.belloni@free-electrons.com> > > CC: Gregory Clement <gregory.clement@free-electrons.com> > > CC: Ingo Molnar <mingo@redhat.com> > > CC: Jason Cooper <jason@lakedaemon.net> > > CC: John Stultz <john.stultz@linaro.org> > > CC: linux-arm-kernel at lists.infradead.org > > CC: linux-kernel at vger.kernel.org > > CC: Linus Walleij <linus.walleij@linaro.org> > > CC: Michael Chan <michael.chan@broadcom.com> > > CC: netdev at vger.kernel.org > > CC: rtc-linux at googlegroups.com > > CC: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> > > CC: Support Opensource <support.opensource@diasemi.com> > > CC: Thomas Gleixner <tglx@linutronix.de> > > CC: x86 at kernel.org > > CC: Baruch Siach <baruch@tkos.co.il> > > CC: Hans Ulli Kroll <ulli.kroll@googlemail.com> > > CC: Vladimir Zapolskiy <vz@mleia.com> > > CC: Sylvain Lemieux <slemieux.tyco@gmail.com> > > CC: Barry Song <baohua@kernel.org> > > CC: Maxime Ripard <maxime.ripard@free-electrons.com> > > CC: Chen-Yu Tsai <wens@csie.org> > > CC: Thierry Reding <thierry.reding@gmail.com> > > CC: Jonathan Hunter <jonathanh@nvidia.com> > > CC: linux-tegra at vger.kernel.org > > CC: patches at opensource.wolfsonmicro.com > > CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> > > CC: Pavel Machek <pavel@ucw.cz> > > CC: Len Brown <len.brown@intel.com> > > CC: linux-pm at vger.kernel.org > > > > 1.9.1 > > > > -- > Alexandre Belloni, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 10:07 ` Alexandre Belloni 0 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-20 10:07 UTC (permalink / raw) To: Benjamin Gaignard Cc: linaro-kernel-cunTk1MwBs8s++Sfvej+rw, adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Michael Chan, netdev-u79uwXL29TY76Z2rM5mHXA, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, Sebastian Hesselbarth, Support Opensource, Thomas Gleixner, x86-DgEjT+Ai2ygdnm+yROfE0A, Baruch Siach, Hans Ulli Kroll, Vladimir Zapolskiy, Sylvain Lemieux, Barry Song, Maxime Ripard On 20/06/2017 at 12:03:48 +0200, Alexandre Belloni wrote: > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > rely on 32bits variables and that will make rtc break in y2038/2016. > > Please don't, because this hide the fact that the hardware will not > handle dates in y2038 anyway and as pointed by Russell a few month ago, > rtc_time_to_tm will be able to catch it but the 64 bit version will > silently ignore it. > Just to be clear, it is fine on your ST hardware because it uses a 64bit counter. Most of the one you patched are using 32 bit counters and so will break anyway. > > > The goal of this series of patches is ti stop using those two functions > > and use instead to safer 64bits ones. > > > > It also remove change .set_mmss to set_mmss64 callback for the same reasons. > > > > Those 51 patches almost clean all the drivers except the few that I haven't > > been able to compile because of cross-toolchains issues (au1xxx, mpc5121, ps3, > > puv3, sun4v, tx4939, starfire, ls1x ...) > > > > Obviously I don't have all those hardwares in my hands so I have only check > > that the patches compile without warnings but it up to each maintainer to > > valid them on real hardware. > > > > Benjamin Gaignard (51): > > x86: rtc: stop using rtc deprecated functions > > x86: intel-mid: vrtc: stop using rtc deprecated functions > > net: broadcom: stop using rtc deprecated functions > > rtc: 88pm80x: stop using rtc deprecated functions > > rtc: 88pm860x: stop using rtc deprecated functions > > rtc: ab-b5ze-s3: stop using rtc deprecated functions > > rtc: ab8500: stop using rtc deprecated functions > > rtc: armada38x: stop using rtc deprecated functions > > rtc: at32ap700x: stop using rtc deprecated functions > > rtc: at91sam9: stop using rtc deprecated functions > > rtc: bfin: stop using rtc deprecated functions > > rtc: coh901331: stop using rtc deprecated functions > > rtc: cpcap: stop using rtc deprecated functions > > rtc: da9063: stop using rtc deprecated functions > > rtc: da9063: stop using rtc deprecated functions > > rtc: davinci: stop using rtc deprecated functions > > rtc: digicolor: stop using rtc deprecated functions > > rtc: dm355evm: stop using rtc deprecated functions > > rtc: ds1305: stop using rtc deprecated functions > > rtc: ds1374: stop using rtc deprecated functions > > rtc: ds1511: stop using rtc deprecated functions > > rtc: ds1553: stop using rtc deprecated functions > > rtc: ds1672: stop using rtc deprecated functions > > rtc: ds2404: stop using rtc deprecated functions > > rtc: ep93xx: stop using rtc deprecated functions > > rtc: gemini: stop using rtc deprecated functions > > rtc: imxdi: stop using rtc deprecated functions > > rtc: jz4740: stop using rtc deprecated functions > > rtc: lpc32xx: stop using rtc deprecated functions > > rtc: mv: stop using rtc deprecated functions > > rtc: omap: stop using rtc deprecated functions > > rtc: pcap: stop using rtc deprecated functions > > rtc: pl030: stop using rtc deprecated functions > > rtc: pl031: stop using rtc deprecated functions > > rtc: pm8xxx: stop using rtc deprecated functions > > rtc: rs5c348: stop using rtc deprecated functions > > rtc: sa1100: stop using rtc deprecated functions > > rtc: sh: stop using rtc deprecated functions > > rtc: sirfsoc: stop using rtc deprecated functions > > rtc: snvs: stop using rtc deprecated functions > > rtc: stk17ta8: stop using rtc deprecated functions > > rtc: stmp3xxx: stop using rtc deprecated functions > > rtc: sun6i: stop using rtc deprecated functions > > rtc: sysfs: stop using rtc deprecated functions > > rtc: tegra stop using rtc deprecated functions > > rtc: test: stop using rtc deprecated functions > > rtc: tps6586: stop using rtc deprecated functions > > rtc: vr41xx: stop using rtc deprecated functions > > rtc: wm831x: stop using rtc deprecated functions > > rtc: xgene stop using rtc deprecated functions > > power: suspend test: stop using rtc deprecated functions > > > > arch/x86/kernel/rtc.c | 6 ++-- > > arch/x86/platform/intel-mid/intel_mid_vrtc.c | 2 +- > > drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +- > > drivers/rtc/rtc-88pm80x.c | 44 +++++++++++++-------------- > > drivers/rtc/rtc-88pm860x.c | 40 ++++++++++++------------- > > drivers/rtc/rtc-ab-b5ze-s3.c | 45 ++++++++-------------------- > > drivers/rtc/rtc-ab8500.c | 26 ++++++++-------- > > drivers/rtc/rtc-armada38x.c | 34 +++++++++------------ > > drivers/rtc/rtc-at32ap700x.c | 29 ++++++++---------- > > drivers/rtc/rtc-at91sam9.c | 18 ++++------- > > drivers/rtc/rtc-bfin.c | 24 +++++++-------- > > drivers/rtc/rtc-coh901331.c | 14 +++++---- > > drivers/rtc/rtc-cpcap.c | 8 ++--- > > drivers/rtc/rtc-da9052.c | 8 ++--- > > drivers/rtc/rtc-da9063.c | 8 ++--- > > drivers/rtc/rtc-davinci.c | 8 ++--- > > drivers/rtc/rtc-digicolor.c | 4 +-- > > drivers/rtc/rtc-dm355evm.c | 6 ++-- > > drivers/rtc/rtc-ds1305.c | 11 +++---- > > drivers/rtc/rtc-ds1374.c | 6 ++-- > > drivers/rtc/rtc-ds1511.c | 2 +- > > drivers/rtc/rtc-ds1553.c | 2 +- > > drivers/rtc/rtc-ds1672.c | 8 ++--- > > drivers/rtc/rtc-ds2404.c | 8 ++--- > > drivers/rtc/rtc-ep93xx.c | 10 +++---- > > drivers/rtc/rtc-gemini.c | 8 ++--- > > drivers/rtc/rtc-imxdi.c | 16 +++++----- > > drivers/rtc/rtc-jz4740.c | 12 ++++---- > > drivers/rtc/rtc-lpc32xx.c | 19 +++++------- > > drivers/rtc/rtc-mv.c | 2 +- > > drivers/rtc/rtc-omap.c | 6 ++-- > > drivers/rtc/rtc-pcap.c | 16 +++++----- > > drivers/rtc/rtc-pl030.c | 24 +++++++-------- > > drivers/rtc/rtc-pl031.c | 31 ++++++++----------- > > drivers/rtc/rtc-pm8xxx.c | 22 +++++++------- > > drivers/rtc/rtc-rs5c348.c | 4 +-- > > drivers/rtc/rtc-sa1100.c | 25 +++++++--------- > > drivers/rtc/rtc-sh.c | 2 +- > > drivers/rtc/rtc-sirfsoc.c | 18 +++++------ > > drivers/rtc/rtc-snvs.c | 14 ++++----- > > drivers/rtc/rtc-stk17ta8.c | 2 +- > > drivers/rtc/rtc-stmp3xxx.c | 12 ++++---- > > drivers/rtc/rtc-sun6i.c | 14 ++++----- > > drivers/rtc/rtc-sysfs.c | 25 ++++++++-------- > > drivers/rtc/rtc-tegra.c | 22 +++++++------- > > drivers/rtc/rtc-test.c | 17 +---------- > > drivers/rtc/rtc-tps6586x.c | 26 ++++++++-------- > > drivers/rtc/rtc-vr41xx.c | 6 ++-- > > drivers/rtc/rtc-wm831x.c | 28 +++++++---------- > > drivers/rtc/rtc-xgene.c | 12 ++++---- > > kernel/power/suspend_test.c | 6 ++-- > > 51 files changed, 342 insertions(+), 420 deletions(-) > > > > -- > > CC: adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > > CC: Alessandro Zummo <a.zummo-BfzFCNDTiLLj+vYz1yj4TQ@public.gmane.org> > > CC: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> > > CC: Gregory Clement <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> > > CC: Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > > CC: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org> > > CC: John Stultz <john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> > > CC: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org > > CC: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > > CC: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> > > CC: Michael Chan <michael.chan-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> > > CC: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > > CC: rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org > > CC: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > CC: Support Opensource <support.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org> > > CC: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org> > > CC: x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org > > CC: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> > > CC: Hans Ulli Kroll <ulli.kroll-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> > > CC: Vladimir Zapolskiy <vz-ChpfBGZJDbMAvxtiuMwx3w@public.gmane.org> > > CC: Sylvain Lemieux <slemieux.tyco-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > CC: Barry Song <baohua-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> > > CC: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> > > CC: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> > > CC: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > CC: Jonathan Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> > > CC: linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > > CC: patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org > > CC: "Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org> > > CC: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org> > > CC: Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> > > CC: linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > > > > 1.9.1 > > > > -- > Alexandre Belloni, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com -- 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 10:07 ` Alexandre Belloni 0 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-20 10:07 UTC (permalink / raw) To: Benjamin Gaignard Cc: linaro-kernel, adi-buildroot-devel, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel, linux-kernel, Linus Walleij, Michael Chan, netdev, rtc-linux, Sebastian Hesselbarth, Support Opensource, Thomas Gleixner, x86, Baruch Siach, Hans Ulli Kroll, Vladimir Zapolskiy, Sylvain Lemieux, Barry Song, Maxime Ripard, Chen-Yu Tsai, Thierry Reding, Jonathan Hunter, linux-tegra, patches, Rafael J. Wysocki, Pavel Machek, Len Brown, linux-pm On 20/06/2017 at 12:03:48 +0200, Alexandre Belloni wrote: > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > rely on 32bits variables and that will make rtc break in y2038/2016. > > Please don't, because this hide the fact that the hardware will not > handle dates in y2038 anyway and as pointed by Russell a few month ago, > rtc_time_to_tm will be able to catch it but the 64 bit version will > silently ignore it. > Just to be clear, it is fine on your ST hardware because it uses a 64bit counter. Most of the one you patched are using 32 bit counters and so will break anyway. > > > The goal of this series of patches is ti stop using those two functions > > and use instead to safer 64bits ones. > > > > It also remove change .set_mmss to set_mmss64 callback for the same reasons. > > > > Those 51 patches almost clean all the drivers except the few that I haven't > > been able to compile because of cross-toolchains issues (au1xxx, mpc5121, ps3, > > puv3, sun4v, tx4939, starfire, ls1x ...) > > > > Obviously I don't have all those hardwares in my hands so I have only check > > that the patches compile without warnings but it up to each maintainer to > > valid them on real hardware. > > > > Benjamin Gaignard (51): > > x86: rtc: stop using rtc deprecated functions > > x86: intel-mid: vrtc: stop using rtc deprecated functions > > net: broadcom: stop using rtc deprecated functions > > rtc: 88pm80x: stop using rtc deprecated functions > > rtc: 88pm860x: stop using rtc deprecated functions > > rtc: ab-b5ze-s3: stop using rtc deprecated functions > > rtc: ab8500: stop using rtc deprecated functions > > rtc: armada38x: stop using rtc deprecated functions > > rtc: at32ap700x: stop using rtc deprecated functions > > rtc: at91sam9: stop using rtc deprecated functions > > rtc: bfin: stop using rtc deprecated functions > > rtc: coh901331: stop using rtc deprecated functions > > rtc: cpcap: stop using rtc deprecated functions > > rtc: da9063: stop using rtc deprecated functions > > rtc: da9063: stop using rtc deprecated functions > > rtc: davinci: stop using rtc deprecated functions > > rtc: digicolor: stop using rtc deprecated functions > > rtc: dm355evm: stop using rtc deprecated functions > > rtc: ds1305: stop using rtc deprecated functions > > rtc: ds1374: stop using rtc deprecated functions > > rtc: ds1511: stop using rtc deprecated functions > > rtc: ds1553: stop using rtc deprecated functions > > rtc: ds1672: stop using rtc deprecated functions > > rtc: ds2404: stop using rtc deprecated functions > > rtc: ep93xx: stop using rtc deprecated functions > > rtc: gemini: stop using rtc deprecated functions > > rtc: imxdi: stop using rtc deprecated functions > > rtc: jz4740: stop using rtc deprecated functions > > rtc: lpc32xx: stop using rtc deprecated functions > > rtc: mv: stop using rtc deprecated functions > > rtc: omap: stop using rtc deprecated functions > > rtc: pcap: stop using rtc deprecated functions > > rtc: pl030: stop using rtc deprecated functions > > rtc: pl031: stop using rtc deprecated functions > > rtc: pm8xxx: stop using rtc deprecated functions > > rtc: rs5c348: stop using rtc deprecated functions > > rtc: sa1100: stop using rtc deprecated functions > > rtc: sh: stop using rtc deprecated functions > > rtc: sirfsoc: stop using rtc deprecated functions > > rtc: snvs: stop using rtc deprecated functions > > rtc: stk17ta8: stop using rtc deprecated functions > > rtc: stmp3xxx: stop using rtc deprecated functions > > rtc: sun6i: stop using rtc deprecated functions > > rtc: sysfs: stop using rtc deprecated functions > > rtc: tegra stop using rtc deprecated functions > > rtc: test: stop using rtc deprecated functions > > rtc: tps6586: stop using rtc deprecated functions > > rtc: vr41xx: stop using rtc deprecated functions > > rtc: wm831x: stop using rtc deprecated functions > > rtc: xgene stop using rtc deprecated functions > > power: suspend test: stop using rtc deprecated functions > > > > arch/x86/kernel/rtc.c | 6 ++-- > > arch/x86/platform/intel-mid/intel_mid_vrtc.c | 2 +- > > drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +- > > drivers/rtc/rtc-88pm80x.c | 44 +++++++++++++-------------- > > drivers/rtc/rtc-88pm860x.c | 40 ++++++++++++------------- > > drivers/rtc/rtc-ab-b5ze-s3.c | 45 ++++++++-------------------- > > drivers/rtc/rtc-ab8500.c | 26 ++++++++-------- > > drivers/rtc/rtc-armada38x.c | 34 +++++++++------------ > > drivers/rtc/rtc-at32ap700x.c | 29 ++++++++---------- > > drivers/rtc/rtc-at91sam9.c | 18 ++++------- > > drivers/rtc/rtc-bfin.c | 24 +++++++-------- > > drivers/rtc/rtc-coh901331.c | 14 +++++---- > > drivers/rtc/rtc-cpcap.c | 8 ++--- > > drivers/rtc/rtc-da9052.c | 8 ++--- > > drivers/rtc/rtc-da9063.c | 8 ++--- > > drivers/rtc/rtc-davinci.c | 8 ++--- > > drivers/rtc/rtc-digicolor.c | 4 +-- > > drivers/rtc/rtc-dm355evm.c | 6 ++-- > > drivers/rtc/rtc-ds1305.c | 11 +++---- > > drivers/rtc/rtc-ds1374.c | 6 ++-- > > drivers/rtc/rtc-ds1511.c | 2 +- > > drivers/rtc/rtc-ds1553.c | 2 +- > > drivers/rtc/rtc-ds1672.c | 8 ++--- > > drivers/rtc/rtc-ds2404.c | 8 ++--- > > drivers/rtc/rtc-ep93xx.c | 10 +++---- > > drivers/rtc/rtc-gemini.c | 8 ++--- > > drivers/rtc/rtc-imxdi.c | 16 +++++----- > > drivers/rtc/rtc-jz4740.c | 12 ++++---- > > drivers/rtc/rtc-lpc32xx.c | 19 +++++------- > > drivers/rtc/rtc-mv.c | 2 +- > > drivers/rtc/rtc-omap.c | 6 ++-- > > drivers/rtc/rtc-pcap.c | 16 +++++----- > > drivers/rtc/rtc-pl030.c | 24 +++++++-------- > > drivers/rtc/rtc-pl031.c | 31 ++++++++----------- > > drivers/rtc/rtc-pm8xxx.c | 22 +++++++------- > > drivers/rtc/rtc-rs5c348.c | 4 +-- > > drivers/rtc/rtc-sa1100.c | 25 +++++++--------- > > drivers/rtc/rtc-sh.c | 2 +- > > drivers/rtc/rtc-sirfsoc.c | 18 +++++------ > > drivers/rtc/rtc-snvs.c | 14 ++++----- > > drivers/rtc/rtc-stk17ta8.c | 2 +- > > drivers/rtc/rtc-stmp3xxx.c | 12 ++++---- > > drivers/rtc/rtc-sun6i.c | 14 ++++----- > > drivers/rtc/rtc-sysfs.c | 25 ++++++++-------- > > drivers/rtc/rtc-tegra.c | 22 +++++++------- > > drivers/rtc/rtc-test.c | 17 +---------- > > drivers/rtc/rtc-tps6586x.c | 26 ++++++++-------- > > drivers/rtc/rtc-vr41xx.c | 6 ++-- > > drivers/rtc/rtc-wm831x.c | 28 +++++++---------- > > drivers/rtc/rtc-xgene.c | 12 ++++---- > > kernel/power/suspend_test.c | 6 ++-- > > 51 files changed, 342 insertions(+), 420 deletions(-) > > > > -- > > CC: adi-buildroot-devel@lists.sourceforge.net > > CC: Alessandro Zummo <a.zummo@towertech.it> > > CC: Alexandre Belloni <alexandre.belloni@free-electrons.com> > > CC: Gregory Clement <gregory.clement@free-electrons.com> > > CC: Ingo Molnar <mingo@redhat.com> > > CC: Jason Cooper <jason@lakedaemon.net> > > CC: John Stultz <john.stultz@linaro.org> > > CC: linux-arm-kernel@lists.infradead.org > > CC: linux-kernel@vger.kernel.org > > CC: Linus Walleij <linus.walleij@linaro.org> > > CC: Michael Chan <michael.chan@broadcom.com> > > CC: netdev@vger.kernel.org > > CC: rtc-linux@googlegroups.com > > CC: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> > > CC: Support Opensource <support.opensource@diasemi.com> > > CC: Thomas Gleixner <tglx@linutronix.de> > > CC: x86@kernel.org > > CC: Baruch Siach <baruch@tkos.co.il> > > CC: Hans Ulli Kroll <ulli.kroll@googlemail.com> > > CC: Vladimir Zapolskiy <vz@mleia.com> > > CC: Sylvain Lemieux <slemieux.tyco@gmail.com> > > CC: Barry Song <baohua@kernel.org> > > CC: Maxime Ripard <maxime.ripard@free-electrons.com> > > CC: Chen-Yu Tsai <wens@csie.org> > > CC: Thierry Reding <thierry.reding@gmail.com> > > CC: Jonathan Hunter <jonathanh@nvidia.com> > > CC: linux-tegra@vger.kernel.org > > CC: patches@opensource.wolfsonmicro.com > > CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> > > CC: Pavel Machek <pavel@ucw.cz> > > CC: Len Brown <len.brown@intel.com> > > CC: linux-pm@vger.kernel.org > > > > 1.9.1 > > > > -- > Alexandre Belloni, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions 2017-06-20 10:03 ` Alexandre Belloni (?) (?) @ 2017-06-20 12:10 ` Pavel Machek -1 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-20 12:10 UTC (permalink / raw) To: Alexandre Belloni Cc: Benjamin Gaignard, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Michael Chan, netdev-u79uwXL29TY76Z2rM5mHXA, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, Sebastian Hesselbarth, Support Opensource, Thomas Gleixner, x86-DgEjT+Ai2ygdnm+yROfE0A, Baruch Siach, Hans Ulli Kroll, Vladimir Zapolskiy, Sylvain Lemieux, Barry Song [-- Attachment #1: Type: text/plain, Size: 1307 bytes --] On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > rely on 32bits variables and that will make rtc break in y2038/2016. > > Please don't, because this hide the fact that the hardware will not > handle dates in y2038 anyway and as pointed by Russell a few month ago, > rtc_time_to_tm will be able to catch it but the 64 bit version will > silently ignore it. Reference? Because rtc on PCs stores date in binary coded decimal, so it is likely to break in 2100, not 2038... Pavel -- (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. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 12:10 ` Pavel Machek 0 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-20 12:10 UTC (permalink / raw) To: linux-arm-kernel On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > rely on 32bits variables and that will make rtc break in y2038/2016. > > Please don't, because this hide the fact that the hardware will not > handle dates in y2038 anyway and as pointed by Russell a few month ago, > rtc_time_to_tm will be able to catch it but the 64 bit version will > silently ignore it. Reference? Because rtc on PCs stores date in binary coded decimal, so it is likely to break in 2100, not 2038... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170620/429aeb11/attachment.sig> ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 12:10 ` Pavel Machek 0 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-20 12:10 UTC (permalink / raw) To: Alexandre Belloni Cc: Benjamin Gaignard, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Michael Chan, netdev-u79uwXL29TY76Z2rM5mHXA, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, Sebastian Hesselbarth, Support Opensource, Thomas Gleixner, x86-DgEjT+Ai2ygdnm+yROfE0A, Baruch Siach, Hans Ulli Kroll, Vladimir Zapolskiy, Sylvain Lemieux, Barry Song [-- Attachment #1: Type: text/plain, Size: 1307 bytes --] On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > rely on 32bits variables and that will make rtc break in y2038/2016. > > Please don't, because this hide the fact that the hardware will not > handle dates in y2038 anyway and as pointed by Russell a few month ago, > rtc_time_to_tm will be able to catch it but the 64 bit version will > silently ignore it. Reference? Because rtc on PCs stores date in binary coded decimal, so it is likely to break in 2100, not 2038... Pavel -- (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. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 12:10 ` Pavel Machek 0 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-20 12:10 UTC (permalink / raw) To: Alexandre Belloni Cc: Benjamin Gaignard, linaro-kernel, adi-buildroot-devel, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel, linux-kernel, Linus Walleij, Michael Chan, netdev, rtc-linux, Sebastian Hesselbarth, Support Opensource, Thomas Gleixner, x86, Baruch Siach, Hans Ulli Kroll, Vladimir Zapolskiy, Sylvain Lemieux, Barry Song, Maxime Ripard, Chen-Yu Tsai, Thierry Reding, Jonathan Hunter, linux-tegra, patches, Rafael J. Wysocki, Len Brown, linux-pm [-- Attachment #1: Type: text/plain, Size: 776 bytes --] On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > rely on 32bits variables and that will make rtc break in y2038/2016. > > Please don't, because this hide the fact that the hardware will not > handle dates in y2038 anyway and as pointed by Russell a few month ago, > rtc_time_to_tm will be able to catch it but the 64 bit version will > silently ignore it. Reference? Because rtc on PCs stores date in binary coded decimal, so it is likely to break in 2100, not 2038... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions 2017-06-20 12:10 ` Pavel Machek (?) (?) @ 2017-06-20 12:24 ` Alexandre Belloni -1 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-20 12:24 UTC (permalink / raw) To: Pavel Machek Cc: Benjamin Gaignard, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Michael Chan, netdev-u79uwXL29TY76Z2rM5mHXA, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, Sebastian Hesselbarth, Support Opensource, Thomas Gleixner, x86-DgEjT+Ai2ygdnm+yROfE0A, Baruch Siach, Hans Ulli Kroll On 20/06/2017 at 14:10:11 +0200, Pavel Machek wrote: > On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: > > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > > rely on 32bits variables and that will make rtc break in y2038/2016. > > > > Please don't, because this hide the fact that the hardware will not > > handle dates in y2038 anyway and as pointed by Russell a few month ago, > > rtc_time_to_tm will be able to catch it but the 64 bit version will > > silently ignore it. > > Reference? Because rtc on PCs stores date in binary coded decimal, so > it is likely to break in 2100, not 2038... I'm not saying it should be done but clearly, that is not the correct thing to do for RTCs that are using a single 32 bits register to store the time. You give one example, I can give you three: armada38x, at91sam9, at32ap700x and that just in the beginning of the series. And yes, on PC, they will break in 2100, other in 2106, some in 2070. I've delayed the tree wide patching until I manage to finish reworking the infrastructure needed to handle the limits of the RTCs. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 12:24 ` Alexandre Belloni 0 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-20 12:24 UTC (permalink / raw) To: linux-arm-kernel On 20/06/2017 at 14:10:11 +0200, Pavel Machek wrote: > On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: > > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > > rely on 32bits variables and that will make rtc break in y2038/2016. > > > > Please don't, because this hide the fact that the hardware will not > > handle dates in y2038 anyway and as pointed by Russell a few month ago, > > rtc_time_to_tm will be able to catch it but the 64 bit version will > > silently ignore it. > > Reference? Because rtc on PCs stores date in binary coded decimal, so > it is likely to break in 2100, not 2038... I'm not saying it should be done but clearly, that is not the correct thing to do for RTCs that are using a single 32 bits register to store the time. You give one example, I can give you three: armada38x, at91sam9, at32ap700x and that just in the beginning of the series. And yes, on PC, they will break in 2100, other in 2106, some in 2070. I've delayed the tree wide patching until I manage to finish reworking the infrastructure needed to handle the limits of the RTCs. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 12:24 ` Alexandre Belloni 0 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-20 12:24 UTC (permalink / raw) To: Pavel Machek Cc: Benjamin Gaignard, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Michael Chan, netdev-u79uwXL29TY76Z2rM5mHXA, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, Sebastian Hesselbarth, Support Opensource, Thomas Gleixner, x86-DgEjT+Ai2ygdnm+yROfE0A, Baruch Siach, Hans Ulli Kroll On 20/06/2017 at 14:10:11 +0200, Pavel Machek wrote: > On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: > > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > > rely on 32bits variables and that will make rtc break in y2038/2016. > > > > Please don't, because this hide the fact that the hardware will not > > handle dates in y2038 anyway and as pointed by Russell a few month ago, > > rtc_time_to_tm will be able to catch it but the 64 bit version will > > silently ignore it. > > Reference? Because rtc on PCs stores date in binary coded decimal, so > it is likely to break in 2100, not 2038... I'm not saying it should be done but clearly, that is not the correct thing to do for RTCs that are using a single 32 bits register to store the time. You give one example, I can give you three: armada38x, at91sam9, at32ap700x and that just in the beginning of the series. And yes, on PC, they will break in 2100, other in 2106, some in 2070. I've delayed the tree wide patching until I manage to finish reworking the infrastructure needed to handle the limits of the RTCs. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 12:24 ` Alexandre Belloni 0 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-20 12:24 UTC (permalink / raw) To: Pavel Machek Cc: Benjamin Gaignard, linaro-kernel, adi-buildroot-devel, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel, linux-kernel, Linus Walleij, Michael Chan, netdev, rtc-linux, Sebastian Hesselbarth, Support Opensource, Thomas Gleixner, x86, Baruch Siach, Hans Ulli Kroll, Vladimir Zapolskiy, Sylvain Lemieux, Barry Song, Maxime Ripard, Chen-Yu Tsai, Thierry Reding, Jonathan Hunter, linux-tegra, patches, Rafael J. Wysocki, Len Brown, linux-pm On 20/06/2017 at 14:10:11 +0200, Pavel Machek wrote: > On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: > > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > > rely on 32bits variables and that will make rtc break in y2038/2016. > > > > Please don't, because this hide the fact that the hardware will not > > handle dates in y2038 anyway and as pointed by Russell a few month ago, > > rtc_time_to_tm will be able to catch it but the 64 bit version will > > silently ignore it. > > Reference? Because rtc on PCs stores date in binary coded decimal, so > it is likely to break in 2100, not 2038... I'm not saying it should be done but clearly, that is not the correct thing to do for RTCs that are using a single 32 bits register to store the time. You give one example, I can give you three: armada38x, at91sam9, at32ap700x and that just in the beginning of the series. And yes, on PC, they will break in 2100, other in 2106, some in 2070. I've delayed the tree wide patching until I manage to finish reworking the infrastructure needed to handle the limits of the RTCs. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 106+ messages in thread
[parent not found: <20170620122400.sm7qqvwyj6cuzarw-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org>]
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions 2017-06-20 12:24 ` Alexandre Belloni (?) (?) @ 2017-06-20 13:26 ` Pavel Machek -1 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-20 13:26 UTC (permalink / raw) To: Alexandre Belloni Cc: Benjamin Gaignard, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Michael Chan, netdev-u79uwXL29TY76Z2rM5mHXA, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, Sebastian Hesselbarth, Support Opensource, Thomas Gleixner, x86-DgEjT+Ai2ygdnm+yROfE0A, Baruch Siach, Hans Ulli Kroll, Vladimir Zapolskiy, Sylvain Lemieux, Barry Song [-- Attachment #1: Type: text/plain, Size: 2410 bytes --] On Tue 2017-06-20 14:24:00, Alexandre Belloni wrote: > On 20/06/2017 at 14:10:11 +0200, Pavel Machek wrote: > > On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: > > > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > > > rely on 32bits variables and that will make rtc break in y2038/2016. > > > > > > Please don't, because this hide the fact that the hardware will not > > > handle dates in y2038 anyway and as pointed by Russell a few month ago, > > > rtc_time_to_tm will be able to catch it but the 64 bit version will > > > silently ignore it. > > > > Reference? Because rtc on PCs stores date in binary coded decimal, so > > it is likely to break in 2100, not 2038... > > I'm not saying it should be done but clearly, that is not the correct > thing to do for RTCs that are using a single 32 bits register to store > the time. > You give one example, I can give you three: armada38x, at91sam9, > at32ap700x and that just in the beginning of the series. I wanted reference to Russell's mail. > And yes, on PC, they will break in 2100, other in 2106, some in 2070. > I've delayed the tree wide patching until I manage to finish reworking > the infrastructure needed to handle the limits of the RTCs. Kernel does not know if it has working RTC or not, so it should use 64bit variables. Merging this -- does not hide anything. Yes, some drivers still may have problems -- so we fix the drivers. You said: > > > rtc_time_to_tm will be able to catch it but the 64 bit will > > > silently ignore it. If that's the case, we may need 64bit version to be smarter.. but we'll still need 64bit variables in the kernel. Pavel -- (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. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 13:26 ` Pavel Machek 0 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-20 13:26 UTC (permalink / raw) To: linux-arm-kernel On Tue 2017-06-20 14:24:00, Alexandre Belloni wrote: > On 20/06/2017 at 14:10:11 +0200, Pavel Machek wrote: > > On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: > > > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > > > rely on 32bits variables and that will make rtc break in y2038/2016. > > > > > > Please don't, because this hide the fact that the hardware will not > > > handle dates in y2038 anyway and as pointed by Russell a few month ago, > > > rtc_time_to_tm will be able to catch it but the 64 bit version will > > > silently ignore it. > > > > Reference? Because rtc on PCs stores date in binary coded decimal, so > > it is likely to break in 2100, not 2038... > > I'm not saying it should be done but clearly, that is not the correct > thing to do for RTCs that are using a single 32 bits register to store > the time. > You give one example, I can give you three: armada38x, at91sam9, > at32ap700x and that just in the beginning of the series. I wanted reference to Russell's mail. > And yes, on PC, they will break in 2100, other in 2106, some in 2070. > I've delayed the tree wide patching until I manage to finish reworking > the infrastructure needed to handle the limits of the RTCs. Kernel does not know if it has working RTC or not, so it should use 64bit variables. Merging this -- does not hide anything. Yes, some drivers still may have problems -- so we fix the drivers. You said: > > > rtc_time_to_tm will be able to catch it but the 64 bit will > > > silently ignore it. If that's the case, we may need 64bit version to be smarter.. but we'll still need 64bit variables in the kernel. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170620/a572ef17/attachment.sig> ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 13:26 ` Pavel Machek 0 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-20 13:26 UTC (permalink / raw) To: Alexandre Belloni Cc: Benjamin Gaignard, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Michael Chan, netdev-u79uwXL29TY76Z2rM5mHXA, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, Sebastian Hesselbarth, Support Opensource, Thomas Gleixner, x86-DgEjT+Ai2ygdnm+yROfE0A, Baruch Siach, Hans Ulli Kroll, Vladimir Zapolskiy, Sylvain Lemieux, Barry Song [-- Attachment #1: Type: text/plain, Size: 2410 bytes --] On Tue 2017-06-20 14:24:00, Alexandre Belloni wrote: > On 20/06/2017 at 14:10:11 +0200, Pavel Machek wrote: > > On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: > > > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > > > rely on 32bits variables and that will make rtc break in y2038/2016. > > > > > > Please don't, because this hide the fact that the hardware will not > > > handle dates in y2038 anyway and as pointed by Russell a few month ago, > > > rtc_time_to_tm will be able to catch it but the 64 bit version will > > > silently ignore it. > > > > Reference? Because rtc on PCs stores date in binary coded decimal, so > > it is likely to break in 2100, not 2038... > > I'm not saying it should be done but clearly, that is not the correct > thing to do for RTCs that are using a single 32 bits register to store > the time. > You give one example, I can give you three: armada38x, at91sam9, > at32ap700x and that just in the beginning of the series. I wanted reference to Russell's mail. > And yes, on PC, they will break in 2100, other in 2106, some in 2070. > I've delayed the tree wide patching until I manage to finish reworking > the infrastructure needed to handle the limits of the RTCs. Kernel does not know if it has working RTC or not, so it should use 64bit variables. Merging this -- does not hide anything. Yes, some drivers still may have problems -- so we fix the drivers. You said: > > > rtc_time_to_tm will be able to catch it but the 64 bit will > > > silently ignore it. If that's the case, we may need 64bit version to be smarter.. but we'll still need 64bit variables in the kernel. Pavel -- (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. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 13:26 ` Pavel Machek 0 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-20 13:26 UTC (permalink / raw) To: Alexandre Belloni Cc: Benjamin Gaignard, linaro-kernel, adi-buildroot-devel, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel, linux-kernel, Linus Walleij, Michael Chan, netdev, rtc-linux, Sebastian Hesselbarth, Support Opensource, Thomas Gleixner, x86, Baruch Siach, Hans Ulli Kroll, Vladimir Zapolskiy, Sylvain Lemieux, Barry Song, Maxime Ripard, Chen-Yu Tsai, Thierry Reding, Jonathan Hunter, linux-tegra, patches, Rafael J. Wysocki, Len Brown, linux-pm [-- Attachment #1: Type: text/plain, Size: 1906 bytes --] On Tue 2017-06-20 14:24:00, Alexandre Belloni wrote: > On 20/06/2017 at 14:10:11 +0200, Pavel Machek wrote: > > On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: > > > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > > > rely on 32bits variables and that will make rtc break in y2038/2016. > > > > > > Please don't, because this hide the fact that the hardware will not > > > handle dates in y2038 anyway and as pointed by Russell a few month ago, > > > rtc_time_to_tm will be able to catch it but the 64 bit version will > > > silently ignore it. > > > > Reference? Because rtc on PCs stores date in binary coded decimal, so > > it is likely to break in 2100, not 2038... > > I'm not saying it should be done but clearly, that is not the correct > thing to do for RTCs that are using a single 32 bits register to store > the time. > You give one example, I can give you three: armada38x, at91sam9, > at32ap700x and that just in the beginning of the series. I wanted reference to Russell's mail. > And yes, on PC, they will break in 2100, other in 2106, some in 2070. > I've delayed the tree wide patching until I manage to finish reworking > the infrastructure needed to handle the limits of the RTCs. Kernel does not know if it has working RTC or not, so it should use 64bit variables. Merging this -- does not hide anything. Yes, some drivers still may have problems -- so we fix the drivers. You said: > > > rtc_time_to_tm will be able to catch it but the 64 bit will > > > silently ignore it. If that's the case, we may need 64bit version to be smarter.. but we'll still need 64bit variables in the kernel. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH 00/51] rtc: stop using rtc deprecated functions 2017-06-20 13:26 ` Pavel Machek (?) (?) @ 2017-06-20 13:37 ` Steve Twiss -1 siblings, 0 replies; 106+ messages in thread From: Steve Twiss @ 2017-06-20 13:37 UTC (permalink / raw) To: Pavel Machek, Alexandre Belloni Cc: Benjamin Gaignard, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Michael Chan, netdev-u79uwXL29TY76Z2rM5mHXA, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, Sebastian Hesselbarth, Support Opensource, Thomas Gleixner Hi Pavel, On 20 June 2017 14:26, Pavel Machek wrote: > Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions > > On Tue 2017-06-20 14:24:00, Alexandre Belloni wrote: > > On 20/06/2017 at 14:10:11 +0200, Pavel Machek wrote: > > > On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: > > > > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > > > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > > > > rely on 32bits variables and that will make rtc break in y2038/2016. > > > > > > > > Please don't, because this hide the fact that the hardware will not > > > > handle dates in y2038 anyway and as pointed by Russell a few month ago, > > > > rtc_time_to_tm will be able to catch it but the 64 bit version will > > > > silently ignore it. > > > > > > Reference? Because rtc on PCs stores date in binary coded decimal, so > > > it is likely to break in 2100, not 2038... > > > > I'm not saying it should be done but clearly, that is not the correct > > thing to do for RTCs that are using a single 32 bits register to store > > the time. > > You give one example, I can give you three: armada38x, at91sam9, > > at32ap700x and that just in the beginning of the series. > > I wanted reference to Russell's mail. This is it. https://patchwork.kernel.org/patch/6219401/ Regards, Steve -- 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 13:37 ` Steve Twiss 0 siblings, 0 replies; 106+ messages in thread From: Steve Twiss @ 2017-06-20 13:37 UTC (permalink / raw) To: linux-arm-kernel Hi Pavel, On 20 June 2017 14:26, Pavel Machek wrote: > Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions > > On Tue 2017-06-20 14:24:00, Alexandre Belloni wrote: > > On 20/06/2017 at 14:10:11 +0200, Pavel Machek wrote: > > > On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: > > > > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > > > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > > > > rely on 32bits variables and that will make rtc break in y2038/2016. > > > > > > > > Please don't, because this hide the fact that the hardware will not > > > > handle dates in y2038 anyway and as pointed by Russell a few month ago, > > > > rtc_time_to_tm will be able to catch it but the 64 bit version will > > > > silently ignore it. > > > > > > Reference? Because rtc on PCs stores date in binary coded decimal, so > > > it is likely to break in 2100, not 2038... > > > > I'm not saying it should be done but clearly, that is not the correct > > thing to do for RTCs that are using a single 32 bits register to store > > the time. > > You give one example, I can give you three: armada38x, at91sam9, > > at32ap700x and that just in the beginning of the series. > > I wanted reference to Russell's mail. This is it. https://patchwork.kernel.org/patch/6219401/ Regards, Steve ^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 13:37 ` Steve Twiss 0 siblings, 0 replies; 106+ messages in thread From: Steve Twiss @ 2017-06-20 13:37 UTC (permalink / raw) To: Pavel Machek, Alexandre Belloni Cc: Benjamin Gaignard, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Michael Chan, netdev-u79uwXL29TY76Z2rM5mHXA, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, Sebastian Hesselbarth, Support Opensource, Thomas Gleixner Hi Pavel, On 20 June 2017 14:26, Pavel Machek wrote: > Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions > > On Tue 2017-06-20 14:24:00, Alexandre Belloni wrote: > > On 20/06/2017 at 14:10:11 +0200, Pavel Machek wrote: > > > On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: > > > > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > > > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > > > > rely on 32bits variables and that will make rtc break in y2038/2016. > > > > > > > > Please don't, because this hide the fact that the hardware will not > > > > handle dates in y2038 anyway and as pointed by Russell a few month ago, > > > > rtc_time_to_tm will be able to catch it but the 64 bit version will > > > > silently ignore it. > > > > > > Reference? Because rtc on PCs stores date in binary coded decimal, so > > > it is likely to break in 2100, not 2038... > > > > I'm not saying it should be done but clearly, that is not the correct > > thing to do for RTCs that are using a single 32 bits register to store > > the time. > > You give one example, I can give you three: armada38x, at91sam9, > > at32ap700x and that just in the beginning of the series. > > I wanted reference to Russell's mail. This is it. https://patchwork.kernel.org/patch/6219401/ Regards, Steve -- 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 13:37 ` Steve Twiss 0 siblings, 0 replies; 106+ messages in thread From: Steve Twiss @ 2017-06-20 13:37 UTC (permalink / raw) To: Pavel Machek, Alexandre Belloni Cc: Benjamin Gaignard, linaro-kernel, adi-buildroot-devel, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel, linux-kernel, Linus Walleij, Michael Chan, netdev, rtc-linux, Sebastian Hesselbarth, Support Opensource, Thomas Gleixner, x86, Baruch Siach, Hans Ulli Kroll, Vladimir Zapolskiy, Sylvain Lemieux, Barry Song, Maxime Ripard, Chen-Yu Tsai, Thierry Reding, Jonathan Hunter, linux-tegra, patches, Rafael J. Wysocki, Len Brown, linux-pm Hi Pavel, On 20 June 2017 14:26, Pavel Machek wrote: > Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions > > On Tue 2017-06-20 14:24:00, Alexandre Belloni wrote: > > On 20/06/2017 at 14:10:11 +0200, Pavel Machek wrote: > > > On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: > > > > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > > > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > > > > rely on 32bits variables and that will make rtc break in y2038/2016. > > > > > > > > Please don't, because this hide the fact that the hardware will not > > > > handle dates in y2038 anyway and as pointed by Russell a few month ago, > > > > rtc_time_to_tm will be able to catch it but the 64 bit version will > > > > silently ignore it. > > > > > > Reference? Because rtc on PCs stores date in binary coded decimal, so > > > it is likely to break in 2100, not 2038... > > > > I'm not saying it should be done but clearly, that is not the correct > > thing to do for RTCs that are using a single 32 bits register to store > > the time. > > You give one example, I can give you three: armada38x, at91sam9, > > at32ap700x and that just in the beginning of the series. > > I wanted reference to Russell's mail. This is it. https://patchwork.kernel.org/patch/6219401/ Regards, Steve ^ permalink raw reply [flat|nested] 106+ messages in thread
[parent not found: <6ED8E3B22081A4459DAC7699F3695FB7018CD96FCD-68WUHU125fLzLL1Oxlh9IgLouzNaz+3S@public.gmane.org>]
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions 2017-06-20 13:37 ` Steve Twiss (?) (?) @ 2017-06-20 13:44 ` Pavel Machek -1 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-20 13:44 UTC (permalink / raw) To: Steve Twiss Cc: Alexandre Belloni, Benjamin Gaignard, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Michael Chan, netdev-u79uwXL29TY76Z2rM5mHXA, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, Sebastian Hesselbarth, Support Opensource [-- Attachment #1: Type: text/plain, Size: 2323 bytes --] On Tue 2017-06-20 13:37:22, Steve Twiss wrote: > Hi Pavel, > > On 20 June 2017 14:26, Pavel Machek wrote: > > > Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions > > > > On Tue 2017-06-20 14:24:00, Alexandre Belloni wrote: > > > On 20/06/2017 at 14:10:11 +0200, Pavel Machek wrote: > > > > On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: > > > > > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > > > > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > > > > > rely on 32bits variables and that will make rtc break in y2038/2016. > > > > > > > > > > Please don't, because this hide the fact that the hardware will not > > > > > handle dates in y2038 anyway and as pointed by Russell a few month ago, > > > > > rtc_time_to_tm will be able to catch it but the 64 bit version will > > > > > silently ignore it. > > > > > > > > Reference? Because rtc on PCs stores date in binary coded decimal, so > > > > it is likely to break in 2100, not 2038... > > > > > > I'm not saying it should be done but clearly, that is not the correct > > > thing to do for RTCs that are using a single 32 bits register to store > > > the time. > > > You give one example, I can give you three: armada38x, at91sam9, > > > at32ap700x and that just in the beginning of the series. > > > > I wanted reference to Russell's mail. > > This is it. > https://patchwork.kernel.org/patch/6219401/ Thanks. 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. Pavel -- (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. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 13:44 ` Pavel Machek 0 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-20 13:44 UTC (permalink / raw) To: linux-arm-kernel On Tue 2017-06-20 13:37:22, Steve Twiss wrote: > Hi Pavel, > > On 20 June 2017 14:26, Pavel Machek wrote: > > > Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions > > > > On Tue 2017-06-20 14:24:00, Alexandre Belloni wrote: > > > On 20/06/2017 at 14:10:11 +0200, Pavel Machek wrote: > > > > On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: > > > > > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > > > > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > > > > > rely on 32bits variables and that will make rtc break in y2038/2016. > > > > > > > > > > Please don't, because this hide the fact that the hardware will not > > > > > handle dates in y2038 anyway and as pointed by Russell a few month ago, > > > > > rtc_time_to_tm will be able to catch it but the 64 bit version will > > > > > silently ignore it. > > > > > > > > Reference? Because rtc on PCs stores date in binary coded decimal, so > > > > it is likely to break in 2100, not 2038... > > > > > > I'm not saying it should be done but clearly, that is not the correct > > > thing to do for RTCs that are using a single 32 bits register to store > > > the time. > > > You give one example, I can give you three: armada38x, at91sam9, > > > at32ap700x and that just in the beginning of the series. > > > > I wanted reference to Russell's mail. > > This is it. > https://patchwork.kernel.org/patch/6219401/ Thanks. 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. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170620/c1b740ae/attachment.sig> ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 13:44 ` Pavel Machek 0 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-20 13:44 UTC (permalink / raw) To: Steve Twiss Cc: Alexandre Belloni, Benjamin Gaignard, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Michael Chan, netdev-u79uwXL29TY76Z2rM5mHXA, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, Sebastian Hesselbarth, Support Opensource [-- Attachment #1: Type: text/plain, Size: 2323 bytes --] On Tue 2017-06-20 13:37:22, Steve Twiss wrote: > Hi Pavel, > > On 20 June 2017 14:26, Pavel Machek wrote: > > > Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions > > > > On Tue 2017-06-20 14:24:00, Alexandre Belloni wrote: > > > On 20/06/2017 at 14:10:11 +0200, Pavel Machek wrote: > > > > On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: > > > > > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > > > > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > > > > > rely on 32bits variables and that will make rtc break in y2038/2016. > > > > > > > > > > Please don't, because this hide the fact that the hardware will not > > > > > handle dates in y2038 anyway and as pointed by Russell a few month ago, > > > > > rtc_time_to_tm will be able to catch it but the 64 bit version will > > > > > silently ignore it. > > > > > > > > Reference? Because rtc on PCs stores date in binary coded decimal, so > > > > it is likely to break in 2100, not 2038... > > > > > > I'm not saying it should be done but clearly, that is not the correct > > > thing to do for RTCs that are using a single 32 bits register to store > > > the time. > > > You give one example, I can give you three: armada38x, at91sam9, > > > at32ap700x and that just in the beginning of the series. > > > > I wanted reference to Russell's mail. > > This is it. > https://patchwork.kernel.org/patch/6219401/ Thanks. 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. Pavel -- (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. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 13:44 ` Pavel Machek 0 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-20 13:44 UTC (permalink / raw) To: Steve Twiss Cc: Alexandre Belloni, Benjamin Gaignard, linaro-kernel, adi-buildroot-devel, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel, linux-kernel, Linus Walleij, Michael Chan, netdev, rtc-linux, Sebastian Hesselbarth, Support Opensource, Thomas Gleixner, x86, Baruch Siach, Hans Ulli Kroll, Vladimir Zapolskiy, Sylvain Lemieux, Barry Song, Maxime Ripard, Chen-Yu Tsai, Thierry Reding, Jonathan Hunter, linux-tegra, patches, Rafael J. Wysocki, Len Brown, linux-pm [-- Attachment #1: Type: text/plain, Size: 1820 bytes --] On Tue 2017-06-20 13:37:22, Steve Twiss wrote: > Hi Pavel, > > On 20 June 2017 14:26, Pavel Machek wrote: > > > Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions > > > > On Tue 2017-06-20 14:24:00, Alexandre Belloni wrote: > > > On 20/06/2017 at 14:10:11 +0200, Pavel Machek wrote: > > > > On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: > > > > > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > > > > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > > > > > rely on 32bits variables and that will make rtc break in y2038/2016. > > > > > > > > > > Please don't, because this hide the fact that the hardware will not > > > > > handle dates in y2038 anyway and as pointed by Russell a few month ago, > > > > > rtc_time_to_tm will be able to catch it but the 64 bit version will > > > > > silently ignore it. > > > > > > > > Reference? Because rtc on PCs stores date in binary coded decimal, so > > > > it is likely to break in 2100, not 2038... > > > > > > I'm not saying it should be done but clearly, that is not the correct > > > thing to do for RTCs that are using a single 32 bits register to store > > > the time. > > > You give one example, I can give you three: armada38x, at91sam9, > > > at32ap700x and that just in the beginning of the series. > > > > I wanted reference to Russell's mail. > > This is it. > https://patchwork.kernel.org/patch/6219401/ Thanks. 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. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions 2017-06-20 13:44 ` Pavel Machek (?) (?) @ 2017-06-20 13:48 ` Alexandre Belloni -1 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-20 13:48 UTC (permalink / raw) To: Pavel Machek Cc: Steve Twiss, Benjamin Gaignard, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Michael Chan, netdev-u79uwXL29TY76Z2rM5mHXA, rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org On 20/06/2017 at 15:44:58 +0200, Pavel Machek wrote: > On Tue 2017-06-20 13:37:22, Steve Twiss wrote: > > Hi Pavel, > > > > On 20 June 2017 14:26, Pavel Machek wrote: > > > > > Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions > > > > > > On Tue 2017-06-20 14:24:00, Alexandre Belloni wrote: > > > > On 20/06/2017 at 14:10:11 +0200, Pavel Machek wrote: > > > > > On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: > > > > > > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > > > > > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > > > > > > rely on 32bits variables and that will make rtc break in y2038/2016. > > > > > > > > > > > > Please don't, because this hide the fact that the hardware will not > > > > > > handle dates in y2038 anyway and as pointed by Russell a few month ago, > > > > > > rtc_time_to_tm will be able to catch it but the 64 bit version will > > > > > > silently ignore it. > > > > > > > > > > Reference? Because rtc on PCs stores date in binary coded decimal, so > > > > > it is likely to break in 2100, not 2038... > > > > > > > > I'm not saying it should be done but clearly, that is not the correct > > > > thing to do for RTCs that are using a single 32 bits register to store > > > > the time. > > > > You give one example, I can give you three: armada38x, at91sam9, > > > > at32ap700x and that just in the beginning of the series. > > > > > > I wanted reference to Russell's mail. > > > > This is it. > > https://patchwork.kernel.org/patch/6219401/ > > Thanks. > > 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. > Yes, we agree on that but I won't cherry pick working patches from a 51 patches series. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 13:48 ` Alexandre Belloni 0 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-20 13:48 UTC (permalink / raw) To: linux-arm-kernel On 20/06/2017 at 15:44:58 +0200, Pavel Machek wrote: > On Tue 2017-06-20 13:37:22, Steve Twiss wrote: > > Hi Pavel, > > > > On 20 June 2017 14:26, Pavel Machek wrote: > > > > > Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions > > > > > > On Tue 2017-06-20 14:24:00, Alexandre Belloni wrote: > > > > On 20/06/2017 at 14:10:11 +0200, Pavel Machek wrote: > > > > > On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: > > > > > > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > > > > > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > > > > > > rely on 32bits variables and that will make rtc break in y2038/2016. > > > > > > > > > > > > Please don't, because this hide the fact that the hardware will not > > > > > > handle dates in y2038 anyway and as pointed by Russell a few month ago, > > > > > > rtc_time_to_tm will be able to catch it but the 64 bit version will > > > > > > silently ignore it. > > > > > > > > > > Reference? Because rtc on PCs stores date in binary coded decimal, so > > > > > it is likely to break in 2100, not 2038... > > > > > > > > I'm not saying it should be done but clearly, that is not the correct > > > > thing to do for RTCs that are using a single 32 bits register to store > > > > the time. > > > > You give one example, I can give you three: armada38x, at91sam9, > > > > at32ap700x and that just in the beginning of the series. > > > > > > I wanted reference to Russell's mail. > > > > This is it. > > https://patchwork.kernel.org/patch/6219401/ > > Thanks. > > 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. > Yes, we agree on that but I won't cherry pick working patches from a 51 patches series. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 13:48 ` Alexandre Belloni 0 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-20 13:48 UTC (permalink / raw) To: Pavel Machek Cc: Steve Twiss, Benjamin Gaignard, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Michael Chan, netdev-u79uwXL29TY76Z2rM5mHXA, rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org On 20/06/2017 at 15:44:58 +0200, Pavel Machek wrote: > On Tue 2017-06-20 13:37:22, Steve Twiss wrote: > > Hi Pavel, > > > > On 20 June 2017 14:26, Pavel Machek wrote: > > > > > Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions > > > > > > On Tue 2017-06-20 14:24:00, Alexandre Belloni wrote: > > > > On 20/06/2017 at 14:10:11 +0200, Pavel Machek wrote: > > > > > On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: > > > > > > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > > > > > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > > > > > > rely on 32bits variables and that will make rtc break in y2038/2016. > > > > > > > > > > > > Please don't, because this hide the fact that the hardware will not > > > > > > handle dates in y2038 anyway and as pointed by Russell a few month ago, > > > > > > rtc_time_to_tm will be able to catch it but the 64 bit version will > > > > > > silently ignore it. > > > > > > > > > > Reference? Because rtc on PCs stores date in binary coded decimal, so > > > > > it is likely to break in 2100, not 2038... > > > > > > > > I'm not saying it should be done but clearly, that is not the correct > > > > thing to do for RTCs that are using a single 32 bits register to store > > > > the time. > > > > You give one example, I can give you three: armada38x, at91sam9, > > > > at32ap700x and that just in the beginning of the series. > > > > > > I wanted reference to Russell's mail. > > > > This is it. > > https://patchwork.kernel.org/patch/6219401/ > > Thanks. > > 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. > Yes, we agree on that but I won't cherry pick working patches from a 51 patches series. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 13:48 ` Alexandre Belloni 0 siblings, 0 replies; 106+ messages in thread From: Alexandre Belloni @ 2017-06-20 13:48 UTC (permalink / raw) To: Pavel Machek Cc: Steve Twiss, Benjamin Gaignard, linaro-kernel, adi-buildroot-devel, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel, linux-kernel, Linus Walleij, Michael Chan, netdev, rtc-linux, Sebastian Hesselbarth, Support Opensource, Thomas Gleixner, x86, Baruch Siach, Hans Ulli Kroll, Vladimir Zapolskiy, Sylvain Lemieux, Barry Song, Maxime Ripard, Chen-Yu Tsai, Thierry Reding, Jonathan Hunter, linux-tegra, patches, Rafael J. Wysocki, Len Brown, linux-pm On 20/06/2017 at 15:44:58 +0200, Pavel Machek wrote: > On Tue 2017-06-20 13:37:22, Steve Twiss wrote: > > Hi Pavel, > > > > On 20 June 2017 14:26, Pavel Machek wrote: > > > > > Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions > > > > > > On Tue 2017-06-20 14:24:00, Alexandre Belloni wrote: > > > > On 20/06/2017 at 14:10:11 +0200, Pavel Machek wrote: > > > > > On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: > > > > > > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > > > > > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > > > > > > rely on 32bits variables and that will make rtc break in y2038/2016. > > > > > > > > > > > > Please don't, because this hide the fact that the hardware will not > > > > > > handle dates in y2038 anyway and as pointed by Russell a few month ago, > > > > > > rtc_time_to_tm will be able to catch it but the 64 bit version will > > > > > > silently ignore it. > > > > > > > > > > Reference? Because rtc on PCs stores date in binary coded decimal, so > > > > > it is likely to break in 2100, not 2038... > > > > > > > > I'm not saying it should be done but clearly, that is not the correct > > > > thing to do for RTCs that are using a single 32 bits register to store > > > > the time. > > > > You give one example, I can give you three: armada38x, at91sam9, > > > > at32ap700x and that just in the beginning of the series. > > > > > > I wanted reference to Russell's mail. > > > > This is it. > > https://patchwork.kernel.org/patch/6219401/ > > Thanks. > > 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. > Yes, we agree on that but I won't cherry pick working patches from a 51 patches series. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 106+ messages in thread
[parent not found: <20170620134827.ubvzhh25klaotupv-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org>]
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions 2017-06-20 13:48 ` Alexandre Belloni (?) (?) @ 2017-06-20 15:07 ` Benjamin Gaignard -1 siblings, 0 replies; 106+ messages in thread From: Benjamin Gaignard @ 2017-06-20 15:07 UTC (permalink / raw) To: Alexandre Belloni Cc: Pavel Machek, Steve Twiss, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Michael Chan, netdev-u79uwXL29TY76Z2rM5mHXA, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, Sebastian Hesselbarth, Support Opensource 2017-06-20 15:48 GMT+02:00 Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>: > On 20/06/2017 at 15:44:58 +0200, Pavel Machek wrote: >> On Tue 2017-06-20 13:37:22, Steve Twiss wrote: >> > Hi Pavel, >> > >> > On 20 June 2017 14:26, Pavel Machek wrote: >> > >> > > Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions >> > > >> > > On Tue 2017-06-20 14:24:00, Alexandre Belloni wrote: >> > > > On 20/06/2017 at 14:10:11 +0200, Pavel Machek wrote: >> > > > > On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: >> > > > > > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: >> > > > > > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they >> > > > > > > rely on 32bits variables and that will make rtc break in y2038/2016. >> > > > > > >> > > > > > Please don't, because this hide the fact that the hardware will not >> > > > > > handle dates in y2038 anyway and as pointed by Russell a few month ago, >> > > > > > rtc_time_to_tm will be able to catch it but the 64 bit version will >> > > > > > silently ignore it. >> > > > > >> > > > > Reference? Because rtc on PCs stores date in binary coded decimal, so >> > > > > it is likely to break in 2100, not 2038... >> > > > >> > > > I'm not saying it should be done but clearly, that is not the correct >> > > > thing to do for RTCs that are using a single 32 bits register to store >> > > > the time. >> > > > You give one example, I can give you three: armada38x, at91sam9, >> > > > at32ap700x and that just in the beginning of the series. >> > > >> > > I wanted reference to Russell's mail. >> > >> > This is it. >> > https://patchwork.kernel.org/patch/6219401/ >> >> Thanks. >> >> 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 agree that will change nothing of hardware limitation but at least the limit will not come from the framework. >> > > Yes, we agree on that but I won't cherry pick working patches from a 51 > patches series. maybe only the acked ones ? > > > -- > 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 15:07 ` Benjamin Gaignard 0 siblings, 0 replies; 106+ messages in thread From: Benjamin Gaignard @ 2017-06-20 15:07 UTC (permalink / raw) To: linux-arm-kernel 2017-06-20 15:48 GMT+02:00 Alexandre Belloni <alexandre.belloni@free-electrons.com>: > On 20/06/2017 at 15:44:58 +0200, Pavel Machek wrote: >> On Tue 2017-06-20 13:37:22, Steve Twiss wrote: >> > Hi Pavel, >> > >> > On 20 June 2017 14:26, Pavel Machek wrote: >> > >> > > Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions >> > > >> > > On Tue 2017-06-20 14:24:00, Alexandre Belloni wrote: >> > > > On 20/06/2017 at 14:10:11 +0200, Pavel Machek wrote: >> > > > > On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: >> > > > > > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: >> > > > > > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they >> > > > > > > rely on 32bits variables and that will make rtc break in y2038/2016. >> > > > > > >> > > > > > Please don't, because this hide the fact that the hardware will not >> > > > > > handle dates in y2038 anyway and as pointed by Russell a few month ago, >> > > > > > rtc_time_to_tm will be able to catch it but the 64 bit version will >> > > > > > silently ignore it. >> > > > > >> > > > > Reference? Because rtc on PCs stores date in binary coded decimal, so >> > > > > it is likely to break in 2100, not 2038... >> > > > >> > > > I'm not saying it should be done but clearly, that is not the correct >> > > > thing to do for RTCs that are using a single 32 bits register to store >> > > > the time. >> > > > You give one example, I can give you three: armada38x, at91sam9, >> > > > at32ap700x and that just in the beginning of the series. >> > > >> > > I wanted reference to Russell's mail. >> > >> > This is it. >> > https://patchwork.kernel.org/patch/6219401/ >> >> Thanks. >> >> 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 agree that will change nothing of hardware limitation but at least the limit will not come from the framework. >> > > Yes, we agree on that but I won't cherry pick working patches from a 51 > patches series. maybe only the acked ones ? > > > -- > Alexandre Belloni, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 15:07 ` Benjamin Gaignard 0 siblings, 0 replies; 106+ messages in thread From: Benjamin Gaignard @ 2017-06-20 15:07 UTC (permalink / raw) To: Alexandre Belloni Cc: Pavel Machek, Steve Twiss, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Michael Chan, netdev-u79uwXL29TY76Z2rM5mHXA, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, Sebastian Hesselbarth, Support Opensource 2017-06-20 15:48 GMT+02:00 Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>: > On 20/06/2017 at 15:44:58 +0200, Pavel Machek wrote: >> On Tue 2017-06-20 13:37:22, Steve Twiss wrote: >> > Hi Pavel, >> > >> > On 20 June 2017 14:26, Pavel Machek wrote: >> > >> > > Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions >> > > >> > > On Tue 2017-06-20 14:24:00, Alexandre Belloni wrote: >> > > > On 20/06/2017 at 14:10:11 +0200, Pavel Machek wrote: >> > > > > On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: >> > > > > > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: >> > > > > > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they >> > > > > > > rely on 32bits variables and that will make rtc break in y2038/2016. >> > > > > > >> > > > > > Please don't, because this hide the fact that the hardware will not >> > > > > > handle dates in y2038 anyway and as pointed by Russell a few month ago, >> > > > > > rtc_time_to_tm will be able to catch it but the 64 bit version will >> > > > > > silently ignore it. >> > > > > >> > > > > Reference? Because rtc on PCs stores date in binary coded decimal, so >> > > > > it is likely to break in 2100, not 2038... >> > > > >> > > > I'm not saying it should be done but clearly, that is not the correct >> > > > thing to do for RTCs that are using a single 32 bits register to store >> > > > the time. >> > > > You give one example, I can give you three: armada38x, at91sam9, >> > > > at32ap700x and that just in the beginning of the series. >> > > >> > > I wanted reference to Russell's mail. >> > >> > This is it. >> > https://patchwork.kernel.org/patch/6219401/ >> >> Thanks. >> >> 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 agree that will change nothing of hardware limitation but at least the limit will not come from the framework. >> > > Yes, we agree on that but I won't cherry pick working patches from a 51 > patches series. maybe only the acked ones ? > > > -- > 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 15:07 ` Benjamin Gaignard 0 siblings, 0 replies; 106+ messages in thread From: Benjamin Gaignard @ 2017-06-20 15:07 UTC (permalink / raw) To: Alexandre Belloni Cc: Pavel Machek, Steve Twiss, linaro-kernel, adi-buildroot-devel, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel, linux-kernel, Linus Walleij, Michael Chan, netdev, rtc-linux, Sebastian Hesselbarth, Support Opensource, Thomas Gleixner, x86, Baruch Siach, Hans Ulli Kroll, Vladimir Zapolskiy, Sylvain Lemieux, Barry Song, Maxime Ripard, Chen-Yu Tsai, Thierry Reding, Jonathan Hunter, linux-tegra, patches, Rafael J. Wysocki, Len Brown, linux-pm 2017-06-20 15:48 GMT+02:00 Alexandre Belloni <alexandre.belloni@free-electrons.com>: > On 20/06/2017 at 15:44:58 +0200, Pavel Machek wrote: >> On Tue 2017-06-20 13:37:22, Steve Twiss wrote: >> > Hi Pavel, >> > >> > On 20 June 2017 14:26, Pavel Machek wrote: >> > >> > > Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions >> > > >> > > On Tue 2017-06-20 14:24:00, Alexandre Belloni wrote: >> > > > On 20/06/2017 at 14:10:11 +0200, Pavel Machek wrote: >> > > > > On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: >> > > > > > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: >> > > > > > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they >> > > > > > > rely on 32bits variables and that will make rtc break in y2038/2016. >> > > > > > >> > > > > > Please don't, because this hide the fact that the hardware will not >> > > > > > handle dates in y2038 anyway and as pointed by Russell a few month ago, >> > > > > > rtc_time_to_tm will be able to catch it but the 64 bit version will >> > > > > > silently ignore it. >> > > > > >> > > > > Reference? Because rtc on PCs stores date in binary coded decimal, so >> > > > > it is likely to break in 2100, not 2038... >> > > > >> > > > I'm not saying it should be done but clearly, that is not the correct >> > > > thing to do for RTCs that are using a single 32 bits register to store >> > > > the time. >> > > > You give one example, I can give you three: armada38x, at91sam9, >> > > > at32ap700x and that just in the beginning of the series. >> > > >> > > I wanted reference to Russell's mail. >> > >> > This is it. >> > https://patchwork.kernel.org/patch/6219401/ >> >> Thanks. >> >> 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 agree that will change nothing of hardware limitation but at least the limit will not come from the framework. >> > > Yes, we agree on that but I won't cherry pick working patches from a 51 > patches series. maybe only the acked ones ? > > > -- > Alexandre Belloni, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com ^ permalink raw reply [flat|nested] 106+ messages in thread
[parent not found: <CA+M3ks68+z6nDtYM8CDpso7SxjB6Nt5E=rOc1yxx=kDz6PUeVQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions 2017-06-20 15:07 ` Benjamin Gaignard (?) (?) @ 2017-06-20 21:15 ` Russell King - ARM Linux -1 siblings, 0 replies; 106+ messages in thread From: Russell King - ARM Linux @ 2017-06-20 21:15 UTC (permalink / raw) To: Benjamin Gaignard Cc: Alexandre Belloni, Baruch Siach, patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E, Linus Walleij, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Thierry Reding, Pavel Machek, Thomas Gleixner, x86-DgEjT+Ai2ygdnm+yROfE0A, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Jason Cooper, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, linux-pm-u79uwXL29TY76Z2rM5mHXA, Hans On Tue, Jun 20, 2017 at 05:07:46PM +0200, Benjamin Gaignard wrote: > 2017-06-20 15:48 GMT+02:00 Alexandre Belloni > <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>: > >> 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. If we convert the 32-bit counter RTC drivers to use 64-bit conversions, then we're completely stuffed, because the lower 32-bits will always be relative to the epoch, and we can't change that without breaking the 64-bit users. So, keep the 32-bit conversion functions, do not deprecate them, and think about the future possibilities. I really think this "get rid of 32-bit time representations" is a much to narrow focus on the wrong problem. You can't ever fix 32-bit time representations by just adding additional zeros into the MSB bits. -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 21:15 ` Russell King - ARM Linux 0 siblings, 0 replies; 106+ messages in thread From: Russell King - ARM Linux @ 2017-06-20 21:15 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jun 20, 2017 at 05:07:46PM +0200, Benjamin Gaignard wrote: > 2017-06-20 15:48 GMT+02:00 Alexandre Belloni > <alexandre.belloni@free-electrons.com>: > >> 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. If we convert the 32-bit counter RTC drivers to use 64-bit conversions, then we're completely stuffed, because the lower 32-bits will always be relative to the epoch, and we can't change that without breaking the 64-bit users. So, keep the 32-bit conversion functions, do not deprecate them, and think about the future possibilities. I really think this "get rid of 32-bit time representations" is a much to narrow focus on the wrong problem. You can't ever fix 32-bit time representations by just adding additional zeros into the MSB bits. -- 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 21:15 ` Russell King - ARM Linux 0 siblings, 0 replies; 106+ messages in thread From: Russell King - ARM Linux @ 2017-06-20 21:15 UTC (permalink / raw) To: Benjamin Gaignard Cc: Alexandre Belloni, Baruch Siach, patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E, Linus Walleij, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Thierry Reding, Pavel Machek, Thomas Gleixner, x86-DgEjT+Ai2ygdnm+yROfE0A, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Jason Cooper, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, linux-pm-u79uwXL29TY76Z2rM5mHXA, Hans On Tue, Jun 20, 2017 at 05:07:46PM +0200, Benjamin Gaignard wrote: > 2017-06-20 15:48 GMT+02:00 Alexandre Belloni > <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>: > >> 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. If we convert the 32-bit counter RTC drivers to use 64-bit conversions, then we're completely stuffed, because the lower 32-bits will always be relative to the epoch, and we can't change that without breaking the 64-bit users. So, keep the 32-bit conversion functions, do not deprecate them, and think about the future possibilities. I really think this "get rid of 32-bit time representations" is a much to narrow focus on the wrong problem. You can't ever fix 32-bit time representations by just adding additional zeros into the MSB bits. -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 21:15 ` Russell King - ARM Linux 0 siblings, 0 replies; 106+ messages in thread From: Russell King - ARM Linux @ 2017-06-20 21:15 UTC (permalink / raw) To: Benjamin Gaignard Cc: Alexandre Belloni, Baruch Siach, patches, Linus Walleij, linux-tegra, Thierry Reding, Pavel Machek, Thomas Gleixner, x86, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel, Jason Cooper, rtc-linux, linux-pm, Hans Ulli Kroll, adi-buildroot-devel, Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan, linux-arm-kernel, Alessandro Zummo, Barry Song, Support Opensource, netdev, Rafael J. Wysocki, linux-kernel, Steve Twiss, Maxime Ripard On Tue, Jun 20, 2017 at 05:07:46PM +0200, Benjamin Gaignard wrote: > 2017-06-20 15:48 GMT+02:00 Alexandre Belloni > <alexandre.belloni@free-electrons.com>: > >> 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. If we convert the 32-bit counter RTC drivers to use 64-bit conversions, then we're completely stuffed, because the lower 32-bits will always be relative to the epoch, and we can't change that without breaking the 64-bit users. So, keep the 32-bit conversion functions, do not deprecate them, and think about the future possibilities. I really think this "get rid of 32-bit time representations" is a much to narrow focus on the wrong problem. You can't ever fix 32-bit time representations by just adding additional zeros into the MSB bits. -- 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
[parent not found: <20170620211536.GM4902-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>]
* RE: [PATCH 00/51] rtc: stop using rtc deprecated functions 2017-06-20 21:15 ` Russell King - ARM Linux (?) (?) @ 2017-06-21 9:26 ` David Laight -1 siblings, 0 replies; 106+ messages in thread From: David Laight @ 2017-06-21 9:26 UTC (permalink / raw) To: 'Russell King - ARM Linux', Benjamin Gaignard Cc: Alexandre Belloni, Baruch Siach, patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E, Linus Walleij, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Thierry Reding, Pavel Machek, Thomas Gleixner, x86-DgEjT+Ai2ygdnm+yROfE0A, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Jason Cooper, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, linux-pm-u79uwXL29TY76Z2rM5mHXA, Hans 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. 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. Problems with things like the x86 bios setting the rtc to stupid values are another matter. ISTR the rtc chip has a bit for 'summertime' that is never set, on a multi-os system you can get multiple summer time changes. David -- 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 9:26 ` David Laight 0 siblings, 0 replies; 106+ messages in thread From: David Laight @ 2017-06-21 9:26 UTC (permalink / raw) To: linux-arm-kernel 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. 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. Problems with things like the x86 bios setting the rtc to stupid values are another matter. ISTR the rtc chip has a bit for 'summertime' that is never set, on a multi-os system you can get multiple summer time changes. David ^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 9:26 ` David Laight 0 siblings, 0 replies; 106+ messages in thread From: David Laight @ 2017-06-21 9:26 UTC (permalink / raw) To: 'Russell King - ARM Linux', Benjamin Gaignard Cc: Alexandre Belloni, Baruch Siach, patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E, Linus Walleij, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Thierry Reding, Pavel Machek, Thomas Gleixner, x86-DgEjT+Ai2ygdnm+yROfE0A, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Jason Cooper, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, linux-pm-u79uwXL29TY76Z2rM5mHXA, Hans 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. 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. Problems with things like the x86 bios setting the rtc to stupid values are another matter. ISTR the rtc chip has a bit for 'summertime' that is never set, on a multi-os system you can get multiple summer time changes. David -- 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 9:26 ` David Laight 0 siblings, 0 replies; 106+ messages in thread From: David Laight @ 2017-06-21 9:26 UTC (permalink / raw) To: 'Russell King - ARM Linux', Benjamin Gaignard Cc: Alexandre Belloni, Baruch Siach, patches, Linus Walleij, linux-tegra, Thierry Reding, Pavel Machek, Thomas Gleixner, x86, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel, Jason Cooper, rtc-linux, linux-pm, Hans Ulli Kroll, adi-buildroot-devel, Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan, linux-arm-kernel, Alessandro Zummo, Barry Song, Support Opensource, netdev, Rafael J. Wysocki, linux-kernel, Steve Twiss, Maxime Ripard 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. 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. Problems with things like the x86 bios setting the rtc to stupid values are another matter. ISTR the rtc chip has a bit for 'summertime' that is never set, on a multi-os system you can get multiple summer time changes. David ^ permalink raw reply [flat|nested] 106+ messages in thread
[parent not found: <063D6719AE5E284EB5DD2968C1650D6DD00278C0-VkEWCZq2GCInGFn1LkZF6NBPR1lH4CV8@public.gmane.org>]
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions 2017-06-21 9:26 ` David Laight (?) @ 2017-06-21 9:35 ` Russell King - ARM Linux -1 siblings, 0 replies; 106+ messages in thread From: Russell King - ARM Linux @ 2017-06-21 9:35 UTC (permalink / raw) To: David Laight Cc: Benjamin Gaignard, Alexandre Belloni, Baruch Siach, patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E, Linus Walleij, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Thierry Reding, Pavel Machek, Thomas Gleixner, x86-DgEjT+Ai2ygdnm+yROfE0A, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel-cunTk1MwBs8s++Sfvej+rw 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 9:35 ` Russell King - ARM Linux 0 siblings, 0 replies; 106+ messages in thread From: Russell King - ARM Linux @ 2017-06-21 9:35 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 9:35 ` Russell King - ARM Linux 0 siblings, 0 replies; 106+ messages in thread From: Russell King - ARM Linux @ 2017-06-21 9:35 UTC (permalink / raw) To: David Laight Cc: Benjamin Gaignard, Alexandre Belloni, Baruch Siach, patches, Linus Walleij, linux-tegra, Thierry Reding, Pavel Machek, Thomas Gleixner, x86, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown, linaro-kernel, Jason Cooper, rtc-linux, linux-pm, Hans Ulli Kroll, adi-buildroot-devel, Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan, linux-arm-kernel, Alessandro Zummo, Barry Song, Support Opensource, netdev, Rafael J. Wysocki, linux-kernel, Steve Twiss, Maxime Ripard 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions 2017-06-20 15:07 ` Benjamin Gaignard (?) (?) @ 2017-06-20 22:08 ` Pavel Machek -1 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-20 22:08 UTC (permalink / raw) To: Benjamin Gaignard Cc: Alexandre Belloni, Steve Twiss, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Michael Chan, netdev-u79uwXL29TY76Z2rM5mHXA, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, Sebastian Hesselbarth, Support Opensource [-- Attachment #1: Type: text/plain, Size: 1820 bytes --] Hi! > >> > This is it. > >> > https://patchwork.kernel.org/patch/6219401/ > >> > >> Thanks. > >> > >> 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 agree that will change nothing of hardware limitation but at least > the limit will > not come from the framework. > > Yes, we agree on that but I won't cherry pick working patches from a 51 > > patches series. Well, it would be actually nice for you to do the cherry picking. That's something maintainers do, because it is hard for contributors to guess maintainer's taste. Anyway, it looks like someone should go through all the RTC drivers, and document their limitations of each driver (date in future when hardware ceases to be useful). If Benjamin has time to do that, I guess that removes all the objections to the series. Regards, Pavel -- (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. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 22:08 ` Pavel Machek 0 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-20 22:08 UTC (permalink / raw) To: linux-arm-kernel Hi! > >> > This is it. > >> > https://patchwork.kernel.org/patch/6219401/ > >> > >> Thanks. > >> > >> 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 agree that will change nothing of hardware limitation but at least > the limit will > not come from the framework. > > Yes, we agree on that but I won't cherry pick working patches from a 51 > > patches series. Well, it would be actually nice for you to do the cherry picking. That's something maintainers do, because it is hard for contributors to guess maintainer's taste. Anyway, it looks like someone should go through all the RTC drivers, and document their limitations of each driver (date in future when hardware ceases to be useful). If Benjamin has time to do that, I guess that removes all the objections to the series. Regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170621/9ea489d7/attachment-0001.sig> ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 22:08 ` Pavel Machek 0 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-20 22:08 UTC (permalink / raw) To: Benjamin Gaignard Cc: Alexandre Belloni, Steve Twiss, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Michael Chan, netdev-u79uwXL29TY76Z2rM5mHXA, rtc-linux-/JYPxA39Uh5TLH3MbocFFw, Sebastian Hesselbarth, Support Opensource [-- Attachment #1: Type: text/plain, Size: 1820 bytes --] Hi! > >> > This is it. > >> > https://patchwork.kernel.org/patch/6219401/ > >> > >> Thanks. > >> > >> 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 agree that will change nothing of hardware limitation but at least > the limit will > not come from the framework. > > Yes, we agree on that but I won't cherry pick working patches from a 51 > > patches series. Well, it would be actually nice for you to do the cherry picking. That's something maintainers do, because it is hard for contributors to guess maintainer's taste. Anyway, it looks like someone should go through all the RTC drivers, and document their limitations of each driver (date in future when hardware ceases to be useful). If Benjamin has time to do that, I guess that removes all the objections to the series. Regards, Pavel -- (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. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-20 22:08 ` Pavel Machek 0 siblings, 0 replies; 106+ messages in thread From: Pavel Machek @ 2017-06-20 22:08 UTC (permalink / raw) To: Benjamin Gaignard Cc: Alexandre Belloni, Steve Twiss, linaro-kernel, adi-buildroot-devel, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel, linux-kernel, Linus Walleij, Michael Chan, netdev, rtc-linux, Sebastian Hesselbarth, Support Opensource, Thomas Gleixner, x86, Baruch Siach, Hans Ulli Kroll, Vladimir Zapolskiy, Sylvain Lemieux, Barry Song, Maxime Ripard, Chen-Yu Tsai, Thierry Reding, Jonathan Hunter, linux-tegra, patches, Rafael J. Wysocki, Len Brown, linux-pm [-- Attachment #1: Type: text/plain, Size: 1309 bytes --] Hi! > >> > This is it. > >> > https://patchwork.kernel.org/patch/6219401/ > >> > >> Thanks. > >> > >> 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 agree that will change nothing of hardware limitation but at least > the limit will > not come from the framework. > > Yes, we agree on that but I won't cherry pick working patches from a 51 > > patches series. Well, it would be actually nice for you to do the cherry picking. That's something maintainers do, because it is hard for contributors to guess maintainer's taste. Anyway, it looks like someone should go through all the RTC drivers, and document their limitations of each driver (date in future when hardware ceases to be useful). If Benjamin has time to do that, I guess that removes all the objections to the series. Regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions 2017-06-20 22:08 ` Pavel Machek (?) @ 2017-06-21 9:14 ` Benjamin Gaignard -1 siblings, 0 replies; 106+ messages in thread From: Benjamin Gaignard @ 2017-06-21 9:14 UTC (permalink / raw) To: Pavel Machek Cc: Alexandre Belloni, Steve Twiss, linaro-kernel-cunTk1MwBs8s++Sfvej+rw, adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Michael Chan, netdev-u79uwXL29TY76Z2rM5mHXA, rtc-linux-/JYPxA39Uh5TLH3MbocFFw 2017-06-21 0:08 GMT+02:00 Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>: > Hi! > >> >> > This is it. >> >> > https://patchwork.kernel.org/patch/6219401/ >> >> >> >> Thanks. >> >> >> >> 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 agree that will change nothing of hardware limitation but at least >> the limit will >> not come from the framework. > >> > Yes, we agree on that but I won't cherry pick working patches from a 51 >> > patches series. > > Well, it would be actually nice for you to do the cherry > picking. That's something maintainers do, because it is hard for > contributors to guess maintainer's taste. > > Anyway, it looks like someone should go through all the RTC drivers, > and document their limitations of each driver (date in future when > hardware ceases to be useful). If Benjamin has time to do that, I > guess that removes all the objections to the series. Without the datasheet I can check in driver code what they do in read/set time functions to understand their limitations. All drivers using BCD like system or spliting day and time should be fixed. I can do a subset of my patches including those driver + the acked ones. Alexandre does that sound reasonable for you ? > Regards, > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 9:14 ` Benjamin Gaignard 0 siblings, 0 replies; 106+ messages in thread From: Benjamin Gaignard @ 2017-06-21 9:14 UTC (permalink / raw) To: linux-arm-kernel 2017-06-21 0:08 GMT+02:00 Pavel Machek <pavel@ucw.cz>: > Hi! > >> >> > This is it. >> >> > https://patchwork.kernel.org/patch/6219401/ >> >> >> >> Thanks. >> >> >> >> 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 agree that will change nothing of hardware limitation but at least >> the limit will >> not come from the framework. > >> > Yes, we agree on that but I won't cherry pick working patches from a 51 >> > patches series. > > Well, it would be actually nice for you to do the cherry > picking. That's something maintainers do, because it is hard for > contributors to guess maintainer's taste. > > Anyway, it looks like someone should go through all the RTC drivers, > and document their limitations of each driver (date in future when > hardware ceases to be useful). If Benjamin has time to do that, I > guess that removes all the objections to the series. Without the datasheet I can check in driver code what they do in read/set time functions to understand their limitations. All drivers using BCD like system or spliting day and time should be fixed. I can do a subset of my patches including those driver + the acked ones. Alexandre does that sound reasonable for you ? > Regards, > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 00/51] rtc: stop using rtc deprecated functions @ 2017-06-21 9:14 ` Benjamin Gaignard 0 siblings, 0 replies; 106+ messages in thread From: Benjamin Gaignard @ 2017-06-21 9:14 UTC (permalink / raw) To: Pavel Machek Cc: Alexandre Belloni, Steve Twiss, linaro-kernel, adi-buildroot-devel, Alessandro Zummo, Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz, linux-arm-kernel, linux-kernel, Linus Walleij, Michael Chan, netdev, rtc-linux, Sebastian Hesselbarth, Support Opensource, Thomas Gleixner, x86, Baruch Siach, Hans Ulli Kroll, Vladimir Zapolskiy, Sylvain Lemieux, Barry Song, Maxime Ripard, Chen-Yu Tsai, Thierry Reding, Jonathan Hunter, linux-tegra, patches, Rafael J. Wysocki, Len Brown, linux-pm 2017-06-21 0:08 GMT+02:00 Pavel Machek <pavel@ucw.cz>: > Hi! > >> >> > This is it. >> >> > https://patchwork.kernel.org/patch/6219401/ >> >> >> >> Thanks. >> >> >> >> 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 agree that will change nothing of hardware limitation but at least >> the limit will >> not come from the framework. > >> > Yes, we agree on that but I won't cherry pick working patches from a 51 >> > patches series. > > Well, it would be actually nice for you to do the cherry > picking. That's something maintainers do, because it is hard for > contributors to guess maintainer's taste. > > Anyway, it looks like someone should go through all the RTC drivers, > and document their limitations of each driver (date in future when > hardware ceases to be useful). If Benjamin has time to do that, I > guess that removes all the objections to the series. Without the datasheet I can check in driver code what they do in read/set time functions to understand their limitations. All drivers using BCD like system or spliting day and time should be fixed. I can do a subset of my patches including those driver + the acked ones. Alexandre does that sound reasonable for you ? > Regards, > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 106+ messages in thread
end of thread, other threads:[~2017-06-21 18:08 UTC | newest] Thread overview: 106+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-06-20 21:35 [PATCH 00/51] rtc: stop using rtc deprecated functions Alexandre Belloni 2017-06-20 21:35 ` Alexandre Belloni 2017-06-20 21:35 ` [rtc-linux] " Alexandre Belloni 2017-06-20 21:35 ` Alexandre Belloni [not found] ` <20170620213507.urobmtg34vzubrdq-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org> 2017-06-20 22:00 ` Thomas Gleixner 2017-06-20 22:00 ` Thomas Gleixner 2017-06-20 22:00 ` Thomas Gleixner 2017-06-20 22:00 ` [rtc-linux] " Thomas Gleixner 2017-06-20 22:00 ` Thomas Gleixner 2017-06-20 22:38 ` Russell King - ARM Linux 2017-06-20 22:38 ` Russell King - ARM Linux 2017-06-20 22:38 ` Russell King - ARM Linux 2017-06-20 22:38 ` [rtc-linux] " Russell King - ARM Linux 2017-06-20 22:38 ` Russell King - ARM Linux 2017-06-21 7:51 ` Pavel Machek 2017-06-21 7:51 ` Pavel Machek 2017-06-21 7:51 ` Pavel Machek 2017-06-21 7:51 ` [rtc-linux] " Pavel Machek 2017-06-21 7:51 ` Pavel Machek 2017-06-21 8:39 ` Alexandre Belloni 2017-06-21 8:39 ` Alexandre Belloni 2017-06-21 8:39 ` Alexandre Belloni 2017-06-21 8:39 ` [rtc-linux] " Alexandre Belloni 2017-06-21 8:39 ` Alexandre Belloni [not found] ` <20170621083907.y3gadsmsoufa5niv-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org> 2017-06-21 6:34 ` Pavel Machek 2017-06-21 6:34 ` Pavel Machek 2017-06-21 6:34 ` Pavel Machek 2017-06-21 6:34 ` [rtc-linux] " Pavel Machek 2017-06-21 6:34 ` Pavel Machek 2017-06-21 12:35 ` Alexandre Belloni 2017-06-21 12:35 ` Alexandre Belloni 2017-06-21 12:35 ` Alexandre Belloni 2017-06-21 12:35 ` [rtc-linux] " Alexandre Belloni 2017-06-21 12:35 ` Alexandre Belloni [not found] ` <20170621123535.b5fvwlydfhnhuqll-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org> 2017-06-21 18:08 ` Pavel Machek 2017-06-21 18:08 ` Pavel Machek 2017-06-21 18:08 ` Pavel Machek 2017-06-21 18:08 ` [rtc-linux] " Pavel Machek 2017-06-21 18:08 ` Pavel Machek 2017-06-21 9:19 ` Russell King - ARM Linux 2017-06-21 9:19 ` Russell King - ARM Linux 2017-06-21 9:19 ` [rtc-linux] " Russell King - ARM Linux 2017-06-21 9:19 ` Russell King - ARM Linux [not found] ` <20170621091948.GP4902-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org> 2017-06-21 9:41 ` Alexandre Belloni 2017-06-21 9:41 ` Alexandre Belloni 2017-06-21 9:41 ` Alexandre Belloni 2017-06-21 9:41 ` [rtc-linux] " Alexandre Belloni 2017-06-21 9:41 ` Alexandre Belloni -- strict thread matches above, loose matches on Subject: below -- 2017-06-20 9:35 Benjamin Gaignard 2017-06-20 9:35 ` Benjamin Gaignard 2017-06-20 9:35 ` Benjamin Gaignard 2017-06-20 9:35 ` Benjamin Gaignard [not found] ` <1497951359-13334-1-git-send-email-benjamin.gaignard-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2017-06-20 10:03 ` Alexandre Belloni 2017-06-20 10:03 ` Alexandre Belloni 2017-06-20 10:03 ` Alexandre Belloni 2017-06-20 10:03 ` Alexandre Belloni [not found] ` <20170620100348.zh4ygvjjgnhxvmvl-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org> 2017-06-20 10:07 ` Alexandre Belloni 2017-06-20 10:07 ` Alexandre Belloni 2017-06-20 10:07 ` Alexandre Belloni 2017-06-20 10:07 ` Alexandre Belloni 2017-06-20 12:10 ` Pavel Machek 2017-06-20 12:10 ` Pavel Machek 2017-06-20 12:10 ` Pavel Machek 2017-06-20 12:10 ` Pavel Machek 2017-06-20 12:24 ` Alexandre Belloni 2017-06-20 12:24 ` Alexandre Belloni 2017-06-20 12:24 ` Alexandre Belloni 2017-06-20 12:24 ` Alexandre Belloni [not found] ` <20170620122400.sm7qqvwyj6cuzarw-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org> 2017-06-20 13:26 ` Pavel Machek 2017-06-20 13:26 ` Pavel Machek 2017-06-20 13:26 ` Pavel Machek 2017-06-20 13:26 ` Pavel Machek 2017-06-20 13:37 ` Steve Twiss 2017-06-20 13:37 ` Steve Twiss 2017-06-20 13:37 ` Steve Twiss 2017-06-20 13:37 ` Steve Twiss [not found] ` <6ED8E3B22081A4459DAC7699F3695FB7018CD96FCD-68WUHU125fLzLL1Oxlh9IgLouzNaz+3S@public.gmane.org> 2017-06-20 13:44 ` Pavel Machek 2017-06-20 13:44 ` Pavel Machek 2017-06-20 13:44 ` Pavel Machek 2017-06-20 13:44 ` Pavel Machek 2017-06-20 13:48 ` Alexandre Belloni 2017-06-20 13:48 ` Alexandre Belloni 2017-06-20 13:48 ` Alexandre Belloni 2017-06-20 13:48 ` Alexandre Belloni [not found] ` <20170620134827.ubvzhh25klaotupv-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org> 2017-06-20 15:07 ` Benjamin Gaignard 2017-06-20 15:07 ` Benjamin Gaignard 2017-06-20 15:07 ` Benjamin Gaignard 2017-06-20 15:07 ` Benjamin Gaignard [not found] ` <CA+M3ks68+z6nDtYM8CDpso7SxjB6Nt5E=rOc1yxx=kDz6PUeVQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2017-06-20 21:15 ` Russell King - ARM Linux 2017-06-20 21:15 ` Russell King - ARM Linux 2017-06-20 21:15 ` Russell King - ARM Linux 2017-06-20 21:15 ` Russell King - ARM Linux [not found] ` <20170620211536.GM4902-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org> 2017-06-21 9:26 ` David Laight 2017-06-21 9:26 ` David Laight 2017-06-21 9:26 ` David Laight 2017-06-21 9:26 ` David Laight [not found] ` <063D6719AE5E284EB5DD2968C1650D6DD00278C0-VkEWCZq2GCInGFn1LkZF6NBPR1lH4CV8@public.gmane.org> 2017-06-21 9:35 ` Russell King - ARM Linux 2017-06-21 9:35 ` Russell King - ARM Linux 2017-06-21 9:35 ` Russell King - ARM Linux 2017-06-20 22:08 ` Pavel Machek 2017-06-20 22:08 ` Pavel Machek 2017-06-20 22:08 ` Pavel Machek 2017-06-20 22:08 ` Pavel Machek 2017-06-21 9:14 ` Benjamin Gaignard 2017-06-21 9:14 ` Benjamin Gaignard 2017-06-21 9:14 ` Benjamin Gaignard
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.