* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
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
In-Reply-To: <1497951359-13334-1-git-send-email-benjamin.gaignard@linaro.org>
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
--
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
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
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
In-Reply-To: <20170620100348.zh4ygvjjgnhxvmvl@piout.net>
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
--
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
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
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
In-Reply-To: <20170620100348.zh4ygvjjgnhxvmvl@piout.net>
[-- Attachment #1: Type: text/plain, Size: 1275 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@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
* [rtc-linux] Re: [PATCH 51/51] power: suspend test: stop using rtc deprecated functions
From: Pavel Machek @ 2017-06-20 12:10 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: linaro-kernel, Rafael J. Wysocki, Len Brown, Alessandro Zummo,
Alexandre Belloni, rtc-linux, linux-pm, linux-kernel
In-Reply-To: <1497951359-13334-52-git-send-email-benjamin.gaignard@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]
On Tue 2017-06-20 11:35:59, 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.
> Stop using those two functions to safer 64bits ones.
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
> CC: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Acked-by: Pavel Machek <pavel@ucw.cz>
--
(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
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
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
In-Reply-To: <20170620121011.GA13221@amd>
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
--
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
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
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
In-Reply-To: <20170620122400.sm7qqvwyj6cuzarw@piout.net>
[-- Attachment #1: Type: text/plain, Size: 2378 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@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
* [rtc-linux] RE: [PATCH 00/51] rtc: stop using rtc deprecated functions
From: Steve Twiss @ 2017-06-20 13:37 UTC (permalink / raw)
To: Pavel Machek, Alexandre Belloni
Cc: Benjamin Gaignard, linaro-kernel@lists.linaro.org,
adi-buildroot-devel@lists.sourceforge.net, Alessandro Zummo,
Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Linus Walleij, Michael Chan,
netdev@vger.kernel.org, rtc-linux@googlegroups.com,
Sebastian Hesselbarth, Support Opensource, Thomas Gleixner,
x86@kernel.org, Baruch Siach, Hans Ulli Kroll, Vladimir Zapolskiy,
Sylvain Lemieux, Barry Song, Maxime Ripard, Chen-Yu Tsai,
Thierry Reding, Jonathan Hunter, linux-tegra@vger.kernel.org,
patches@opensource.wolfsonmicro.com, Rafael J. Wysocki, Len Brown,
linux-pm@vger.kernel.org
In-Reply-To: <20170620132620.GA16881@amd>
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@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [rtc-linux] RE: [PATCH 14/51] rtc: da9063: stop using rtc deprecated functions
From: Steve Twiss @ 2017-06-20 13:41 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: linaro-kernel@lists.linaro.org, Support Opensource,
Alessandro Zummo, Alexandre Belloni, rtc-linux@googlegroups.com,
linux-kernel@vger.kernel.org
In-Reply-To: <1497951359-13334-15-git-send-email-benjamin.gaignard@linaro.org>
Hi Benjamin,
On 20 June 2017 10:35, Benjamin Gaignard wrote:
> Subject: [PATCH 14/51] rtc: da9063: stop using rtc deprecated functions
Probably this subject should be "rtc: da9052" not 63.
> 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.
> Stop using those two functions to safer 64bits ones.
>
[...]
> ---
> drivers/rtc/rtc-da9052.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/rtc/rtc-da9052.c b/drivers/rtc/rtc-da9052.c
> index 4273377..99a0489 100644
> --- a/drivers/rtc/rtc-da9052.c
> +++ b/drivers/rtc/rtc-da9052.c
> @@ -104,17 +104,15 @@ static int da9052_read_alarm(struct da9052_rtc
> *rtc, struct rtc_time *rtc_tm)
> static int da9052_set_alarm(struct da9052_rtc *rtc, struct rtc_time *rtc_tm)
> {
> struct da9052 *da9052 = rtc->da9052;
> - unsigned long alm_time;
> + unsigned long long alm_time;
> int ret;
> uint8_t v[3];
>
> - ret = rtc_tm_to_time(rtc_tm, &alm_time);
> - if (ret != 0)
> - return ret;
> + alm_time = rtc_tm_to_time64(rtc_tm);
But they kind of use the same functions anyway.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/rtc.h?h=v4.12-rc6#n35
And I think they they are abstracted on purpose.
The DA9052/53 hardware can only handle alarms up to the end of 2063.
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@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
From: Pavel Machek @ 2017-06-20 13:44 UTC (permalink / raw)
To: Steve Twiss
Cc: Alexandre Belloni, Benjamin Gaignard,
linaro-kernel@lists.linaro.org,
adi-buildroot-devel@lists.sourceforge.net, Alessandro Zummo,
Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Linus Walleij, Michael Chan,
netdev@vger.kernel.org, rtc-linux@googlegroups.com,
Sebastian Hesselbarth, Support Opensource, Thomas Gleixner,
x86@kernel.org, Baruch Siach, Hans Ulli Kroll, Vladimir Zapolskiy,
Sylvain Lemieux, Barry Song, Maxime Ripard, Chen-Yu Tsai,
Thierry Reding, Jonathan Hunter, linux-tegra@vger.kernel.org,
patches@opensource.wolfsonmicro.com, Rafael J. Wysocki, Len Brown,
linux-pm@vger.kernel.org
In-Reply-To: <6ED8E3B22081A4459DAC7699F3695FB7018CD96FCD@SW-EX-MBX02.diasemi.com>
[-- Attachment #1: Type: text/plain, Size: 2291 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@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
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
From: Alexandre Belloni @ 2017-06-20 13:48 UTC (permalink / raw)
To: Pavel Machek
Cc: Steve Twiss, Benjamin Gaignard, linaro-kernel@lists.linaro.org,
adi-buildroot-devel@lists.sourceforge.net, Alessandro Zummo,
Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Linus Walleij, Michael Chan,
netdev@vger.kernel.org, rtc-linux@googlegroups.com,
Sebastian Hesselbarth, Support Opensource, Thomas Gleixner,
x86@kernel.org, Baruch Siach, Hans Ulli Kroll, Vladimir Zapolskiy,
Sylvain Lemieux, Barry Song, Maxime Ripard, Chen-Yu Tsai,
Thierry Reding, Jonathan Hunter, linux-tegra@vger.kernel.org,
patches@opensource.wolfsonmicro.com, Rafael J. Wysocki, Len Brown,
linux-pm@vger.kernel.org
In-Reply-To: <20170620134458.GA10104@amd>
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
--
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
* [rtc-linux] Re: [PATCH 14/51] rtc: da9063: stop using rtc deprecated functions
From: Benjamin Gaignard @ 2017-06-20 14:18 UTC (permalink / raw)
To: Steve Twiss
Cc: linaro-kernel@lists.linaro.org, Support Opensource,
Alessandro Zummo, Alexandre Belloni, rtc-linux@googlegroups.com,
linux-kernel@vger.kernel.org
In-Reply-To: <6ED8E3B22081A4459DAC7699F3695FB7018CD9700F@SW-EX-MBX02.diasemi.com>
2017-06-20 15:41 GMT+02:00 Steve Twiss <stwiss.opensource@diasemi.com>:
> Hi Benjamin,
>
> On 20 June 2017 10:35, Benjamin Gaignard wrote:
>
>> Subject: [PATCH 14/51] rtc: da9063: stop using rtc deprecated functions
>
> Probably this subject should be "rtc: da9052" not 63.
yes you are right this patch is for da9052
>
>> 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.
>> Stop using those two functions to safer 64bits ones.
>>
> [...]
>
>> ---
>> drivers/rtc/rtc-da9052.c | 8 +++-----
>> 1 file changed, 3 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/rtc/rtc-da9052.c b/drivers/rtc/rtc-da9052.c
>> index 4273377..99a0489 100644
>> --- a/drivers/rtc/rtc-da9052.c
>> +++ b/drivers/rtc/rtc-da9052.c
>> @@ -104,17 +104,15 @@ static int da9052_read_alarm(struct da9052_rtc
>> *rtc, struct rtc_time *rtc_tm)
>> static int da9052_set_alarm(struct da9052_rtc *rtc, struct rtc_time *rtc_tm)
>> {
>> struct da9052 *da9052 = rtc->da9052;
>> - unsigned long alm_time;
>> + unsigned long long alm_time;
>> int ret;
>> uint8_t v[3];
>>
>> - ret = rtc_tm_to_time(rtc_tm, &alm_time);
>> - if (ret != 0)
>> - return ret;
>> + alm_time = rtc_tm_to_time64(rtc_tm);
>
> But they kind of use the same functions anyway.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/rtc.h?h=v4.12-rc6#n35
> And I think they they are abstracted on purpose.
>
> The DA9052/53 hardware can only handle alarms up to the end of 2063.
That is the hardware limits but I don't know if we should align
framework functions to
for each driver limitation or use 64 bits functions everywhere.
but this discussion is on going on another thread...
>
> 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@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
From: Benjamin Gaignard @ 2017-06-20 15:07 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Pavel Machek, Steve Twiss, linaro-kernel@lists.linaro.org,
adi-buildroot-devel@lists.sourceforge.net, Alessandro Zummo,
Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Linus Walleij, Michael Chan,
netdev@vger.kernel.org, rtc-linux@googlegroups.com,
Sebastian Hesselbarth, Support Opensource, Thomas Gleixner,
x86@kernel.org, Baruch Siach, Hans Ulli Kroll, Vladimir Zapolskiy,
Sylvain Lemieux, Barry Song, Maxime Ripard, Chen-Yu Tsai,
Thierry Reding, Jonathan Hunter, linux-tegra@vger.kernel.org,
patches@opensource.wolfsonmicro.com, Rafael J. Wysocki, Len Brown,
linux-pm@vger.kernel.org
In-Reply-To: <20170620134827.ubvzhh25klaotupv@piout.net>
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
--
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
* [rtc-linux] Re: [PATCH 07/51] rtc: ab8500: stop using rtc deprecated functions
From: Linus Walleij @ 2017-06-20 16:06 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: linaro-kernel, Alessandro Zummo, Alexandre Belloni,
rtc-linux@googlegroups.com, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1497951359-13334-8-git-send-email-benjamin.gaignard@linaro.org>
On Tue, Jun 20, 2017 at 11:35 AM, Benjamin Gaignard
<benjamin.gaignard@linaro.org> 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.
> Stop using those two functions to safer 64bits ones.
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
> CC: Linus Walleij <linus.walleij@linaro.org>
> CC: Alessandro Zummo <a.zummo@towertech.it>
> CC: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> CC: rtc-linux@googlegroups.com
> CC: linux-kernel@vger.kernel.org
> CC: linux-arm-kernel@lists.infradead.org
Looks fine.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
--
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
* Re: [rtc-linux] [PATCH 12/51] rtc: coh901331: stop using rtc deprecated functions
From: Linus Walleij @ 2017-06-20 16:07 UTC (permalink / raw)
To: rtc-linux@googlegroups.com
Cc: Benjamin Gaignard, linaro-kernel, Alessandro Zummo,
Alexandre Belloni, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1497951359-13334-13-git-send-email-benjamin.gaignard@linaro.org>
On Tue, Jun 20, 2017 at 11:35 AM, Benjamin Gaignard
<benjamin.gaignard@linaro.org> 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.
> Stop using those two functions to safer 64bits ones.
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
> CC: Linus Walleij <linus.walleij@linaro.org>
> CC: Alessandro Zummo <a.zummo@towertech.it>
> CC: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> CC: rtc-linux@googlegroups.com
> CC: linux-kernel@vger.kernel.org
> CC: linux-arm-kernel@lists.infradead.org
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
--
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
* [rtc-linux] Re: [PATCH 34/51] rtc: pl031: stop using rtc deprecated functions
From: Linus Walleij @ 2017-06-20 16:08 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: linaro-kernel, Alessandro Zummo, Alexandre Belloni,
rtc-linux@googlegroups.com, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1497951359-13334-35-git-send-email-benjamin.gaignard@linaro.org>
On Tue, Jun 20, 2017 at 11:35 AM, Benjamin Gaignard
<benjamin.gaignard@linaro.org> 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.
> Stop using those two functions to safer 64bits ones.
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
> CC: Linus Walleij <linus.walleij@linaro.org>
> CC: Alessandro Zummo <a.zummo@towertech.it>
> CC: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> CC: rtc-linux@googlegroups.com
> CC: linux-kernel@vger.kernel.org
> CC: linux-arm-kernel@lists.infradead.org
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
--
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
* [rtc-linux] Re: [PATCH 34/51] rtc: pl031: stop using rtc deprecated functions
From: Russell King - ARM Linux @ 2017-06-20 21:05 UTC (permalink / raw)
To: Linus Walleij
Cc: Benjamin Gaignard, Alessandro Zummo, linaro-kernel,
rtc-linux@googlegroups.com, linux-kernel@vger.kernel.org,
Alexandre Belloni, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CACRpkdZsdwuytW5RHSdd5t9MSyYnhV1nNNKOR1VUzqEgicFqUw@mail.gmail.com>
On Tue, Jun 20, 2017 at 06:08:48PM +0200, Linus Walleij wrote:
> On Tue, Jun 20, 2017 at 11:35 AM, Benjamin Gaignard
> <benjamin.gaignard@linaro.org> 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.
> > Stop using those two functions to safer 64bits ones.
> >
> > Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
> > CC: Linus Walleij <linus.walleij@linaro.org>
> > CC: Alessandro Zummo <a.zummo@towertech.it>
> > CC: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> > CC: rtc-linux@googlegroups.com
> > CC: linux-kernel@vger.kernel.org
> > CC: linux-arm-kernel@lists.infradead.org
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
Naked-again-by: Russell King
Really, people need to stop re-posting the same patches that have
already been naked.
This patch fixes NOTHING.
--
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
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
From: Russell King - ARM Linux @ 2017-06-20 21:15 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: Alexandre Belloni, Baruch Siach,
patches@opensource.wolfsonmicro.com, Linus Walleij,
linux-tegra@vger.kernel.org, Thierry Reding, Pavel Machek,
Thomas Gleixner, x86@kernel.org, Jonathan Hunter, Chen-Yu Tsai,
Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown,
linaro-kernel@lists.linaro.org, Jason Cooper,
rtc-linux@googlegroups.com, linux-pm@vger.kernel.org,
Hans Ulli Kroll, adi-buildroot-devel@lists.sourceforge.net,
Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan,
linux-arm-kernel@lists.infradead.org, Alessandro Zummo,
Barry Song, Support Opensource, netdev@vger.kernel.org,
Rafael J. Wysocki, linux-kernel@vger.kernel.org, Steve Twiss,
Maxime Ripard
In-Reply-To: <CA+M3ks68+z6nDtYM8CDpso7SxjB6Nt5E=rOc1yxx=kDz6PUeVQ@mail.gmail.com>
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.
--
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
* [rtc-linux] Re: [PATCH 12/51] rtc: coh901331: stop using rtc deprecated functions
From: Russell King - ARM Linux @ 2017-06-20 21:21 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: Alessandro Zummo, linaro-kernel, rtc-linux, Linus Walleij,
linux-kernel, Alexandre Belloni, linux-arm-kernel
In-Reply-To: <1497951359-13334-13-git-send-email-benjamin.gaignard@linaro.org>
On Tue, Jun 20, 2017 at 11:35:20AM +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.
> Stop using those two functions to safer 64bits ones.
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
> CC: Linus Walleij <linus.walleij@linaro.org>
> CC: Alessandro Zummo <a.zummo@towertech.it>
> CC: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> CC: rtc-linux@googlegroups.com
> CC: linux-kernel@vger.kernel.org
> CC: linux-arm-kernel@lists.infradead.org
> ---
> drivers/rtc/rtc-coh901331.c | 14 ++++++++------
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/rtc/rtc-coh901331.c b/drivers/rtc/rtc-coh901331.c
> index cfc4141..5645011 100644
> --- a/drivers/rtc/rtc-coh901331.c
> +++ b/drivers/rtc/rtc-coh901331.c
> @@ -80,7 +80,8 @@ static int coh901331_read_time(struct device *dev, struct rtc_time *tm)
> clk_enable(rtap->clk);
> /* Check if the time is valid */
> if (readl(rtap->virtbase + COH901331_VALID)) {
> - rtc_time_to_tm(readl(rtap->virtbase + COH901331_CUR_TIME), tm);
> + rtc_time64_to_tm(
> + (u64)readl(rtap->virtbase + COH901331_CUR_TIME), tm);
> clk_disable(rtap->clk);
> return rtc_valid_tm(tm);
> }
> @@ -88,7 +89,7 @@ static int coh901331_read_time(struct device *dev, struct rtc_time *tm)
> return -EINVAL;
> }
>
> -static int coh901331_set_mmss(struct device *dev, unsigned long secs)
> +static int coh901331_set_mmss64(struct device *dev, time64_t secs)
Do you realise how stupid this is? Here, you're implicitly truncating
the 64-bit time value to 32-bit when you write it into the register.
So, when your clock wraps past 7 February 2106 (*not* 2038), when you
next read it, you read a date in 1970.
Exactly the same happens with the existing implementation, so this
fixes nothing at all. As I've said in my other mail, these changes
make it harder to fix the problem, because you're stuck with that
truncation - you can never do anything but truncate it.
Keeping the 32-bit conversion functions allows us to wind the date
progressively forward if we so choose.
Sure, if we don't want to maintain two conversion functions, then we
can define the 32-bit conversion functions in terms of the 64-bit
versions, but do _not_ get rid of them.
--
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
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
From: Alexandre Belloni @ 2017-06-20 21:35 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Benjamin Gaignard, Baruch Siach,
patches@opensource.wolfsonmicro.com, Linus Walleij,
linux-tegra@vger.kernel.org, Thierry Reding, Pavel Machek,
Thomas Gleixner, x86@kernel.org, Jonathan Hunter, Chen-Yu Tsai,
Ingo Molnar, Sylvain Lemieux, Sebastian Hesselbarth, Len Brown,
linaro-kernel@lists.linaro.org, Jason Cooper,
rtc-linux@googlegroups.com, linux-pm@vger.kernel.org,
Hans Ulli Kroll, adi-buildroot-devel@lists.sourceforge.net,
Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan,
linux-arm-kernel@lists.infradead.org, Alessandro Zummo,
Barry Song, Support Opensource, netdev@vger.kernel.org,
Rafael J. Wysocki, linux-kernel@vger.kernel.org, Steve Twiss,
Maxime Ripard
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
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
From: Thomas Gleixner @ 2017-06-20 22:00 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Russell King - ARM Linux, Benjamin Gaignard, Baruch Siach,
patches@opensource.wolfsonmicro.com, Linus Walleij,
linux-tegra@vger.kernel.org, Thierry Reding, Pavel Machek,
x86@kernel.org, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar,
Sylvain Lemieux, Sebastian Hesselbarth, Len Brown,
linaro-kernel@lists.linaro.org, Jason Cooper,
rtc-linux@googlegroups.com, linux-pm@vger.kernel.org,
Hans Ulli Kroll, adi-buildroot-devel@lists.sourceforge.net,
Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan,
linux-arm-kernel@lists.infradead.org, Alessandro Zummo,
Barry Song, Support Opensource, netdev@vger.kernel.org,
Rafael J. Wysocki, linux-kernel@vger.kernel.org, Steve Twiss,
Maxime Ripard
In-Reply-To: <20170620213507.urobmtg34vzubrdq@piout.net>
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
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
From: Pavel Machek @ 2017-06-20 22:08 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: Alexandre Belloni, Steve Twiss, linaro-kernel@lists.linaro.org,
adi-buildroot-devel@lists.sourceforge.net, Alessandro Zummo,
Gregory Clement, Ingo Molnar, Jason Cooper, John Stultz,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Linus Walleij, Michael Chan,
netdev@vger.kernel.org, rtc-linux@googlegroups.com,
Sebastian Hesselbarth, Support Opensource, Thomas Gleixner,
x86@kernel.org, Baruch Siach, Hans Ulli Kroll, Vladimir Zapolskiy,
Sylvain Lemieux, Barry Song, Maxime Ripard, Chen-Yu Tsai,
Thierry Reding, Jonathan Hunter, linux-tegra@vger.kernel.org,
patches@opensource.wolfsonmicro.com, Rafael J. Wysocki, Len Brown,
linux-pm@vger.kernel.org
In-Reply-To: <CA+M3ks68+z6nDtYM8CDpso7SxjB6Nt5E=rOc1yxx=kDz6PUeVQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1788 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@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
* [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
From: Russell King - ARM Linux @ 2017-06-20 22:38 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Alexandre Belloni, Benjamin Gaignard, Baruch Siach,
patches@opensource.wolfsonmicro.com, Linus Walleij,
linux-tegra@vger.kernel.org, Thierry Reding, Pavel Machek,
x86@kernel.org, Jonathan Hunter, Chen-Yu Tsai, Ingo Molnar,
Sylvain Lemieux, Sebastian Hesselbarth, Len Brown,
linaro-kernel@lists.linaro.org, Jason Cooper,
rtc-linux@googlegroups.com, linux-pm@vger.kernel.org,
Hans Ulli Kroll, adi-buildroot-devel@lists.sourceforge.net,
Vladimir Zapolskiy, John Stultz, Gregory Clement, Michael Chan,
linux-arm-kernel@lists.infradead.org, Alessandro Zummo,
Barry Song, Support Opensource, netdev@vger.kernel.org,
Rafael J. Wysocki, linux-kernel@vger.kernel.org, Steve Twiss,
Maxime Ripard
In-Reply-To: <alpine.DEB.2.20.1706202343120.2157@nanos>
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
* [rtc-linux] Re: [PATCH 13/51] rtc: cpcap: stop using rtc deprecated functions
From: kbuild test robot @ 2017-06-21 4:37 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: kbuild-all, benjamin.gaignard, linaro-kernel, Alessandro Zummo,
Alexandre Belloni, rtc-linux, linux-kernel
In-Reply-To: <1497951359-13334-14-git-send-email-benjamin.gaignard@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]
Hi Benjamin,
[auto build test ERROR on abelloni/rtc-next]
[also build test ERROR on v4.12-rc6 next-20170620]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Benjamin-Gaignard/rtc-stop-using-rtc-deprecated-functions/20170621-044455
base: https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git rtc-next
config: arm-omap2plus_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> ERROR: "__aeabi_uldivmod" [drivers/rtc/rtc-cpcap.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
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: .config.gz --]
[-- Type: application/gzip, Size: 29729 bytes --]
^ permalink raw reply
* [rtc-linux] Re: [PATCH 32/51] rtc: pcap: stop using rtc deprecated functions
From: kbuild test robot @ 2017-06-21 4:45 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: kbuild-all, benjamin.gaignard, linaro-kernel, Alessandro Zummo,
Alexandre Belloni, rtc-linux, linux-kernel
In-Reply-To: <1497951359-13334-33-git-send-email-benjamin.gaignard@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1711 bytes --]
Hi Benjamin,
[auto build test ERROR on abelloni/rtc-next]
[also build test ERROR on v4.12-rc6 next-20170620]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Benjamin-Gaignard/rtc-stop-using-rtc-deprecated-functions/20170621-044455
base: https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git rtc-next
config: i386-randconfig-b0-06210824 (attached as .config)
compiler: gcc-5 (Debian 5.4.1-2) 5.4.1 20160904
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/built-in.o: In function `pcap_rtc_set_mmss64':
>> rtc-pcap.c:(.text+0x18a7e0): undefined reference to `__moddi3'
>> rtc-pcap.c:(.text+0x18a800): undefined reference to `__divdi3'
drivers/built-in.o: In function `pcap_rtc_set_alarm':
>> rtc-pcap.c:(.text+0x18a83e): undefined reference to `__umoddi3'
>> rtc-pcap.c:(.text+0x18a85e): undefined reference to `__udivdi3'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
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: .config.gz --]
[-- Type: application/gzip, Size: 28867 bytes --]
^ permalink raw reply
* [rtc-linux] Re: [PATCH 32/51] rtc: pcap: stop using rtc deprecated functions
From: kbuild test robot @ 2017-06-21 5:07 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: kbuild-all, benjamin.gaignard, linaro-kernel, Alessandro Zummo,
Alexandre Belloni, rtc-linux, linux-kernel
In-Reply-To: <1497951359-13334-33-git-send-email-benjamin.gaignard@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1898 bytes --]
Hi Benjamin,
[auto build test ERROR on abelloni/rtc-next]
[also build test ERROR on v4.12-rc6 next-20170620]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Benjamin-Gaignard/rtc-stop-using-rtc-deprecated-functions/20170621-044455
base: https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git rtc-next
config: arm-ezx_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
drivers/built-in.o: In function `pcap_rtc_set_mmss64':
>> hid-generic.c:(.text+0xac5b8): undefined reference to `__aeabi_ldivmod'
hid-generic.c:(.text+0xac5dc): undefined reference to `__aeabi_ldivmod'
drivers/built-in.o: In function `pcap_rtc_set_alarm':
>> hid-generic.c:(.text+0xac61c): undefined reference to `__aeabi_uldivmod'
hid-generic.c:(.text+0xac640): undefined reference to `__aeabi_uldivmod'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
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: .config.gz --]
[-- Type: application/gzip, Size: 19642 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox