[PATCH 00/51] rtc: stop using rtc deprecated functions

[PATCH 00/51] rtc: stop using rtc deprecated functions

[Benjamin Gaignard]

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.

[PATCH 03/51] net: broadcom: stop using rtc deprecated functions

[Benjamin Gaignard]

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: Michael Chan <michael.chan@broadcom.com>
CC: netdev@vger.kernel.org
CC: linux-kernel@vger.kernel.org
---
 drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index b56c54d..9fef202 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -4703,7 +4703,7 @@ int bnxt_hwrm_fw_set_time(struct bnxt *bp)
 		return -EOPNOTSUPP;
 
 	do_gettimeofday(&tv);
-	rtc_time_to_tm(tv.tv_sec, &tm);
+	rtc_time64_to_tm(tv.tv_sec, &tm);
 	bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_FW_SET_TIME, -1, -1);
 	req.year = cpu_to_le16(1900 + tm.tm_year);
 	req.month = 1 + tm.tm_mon;
-- 
1.9.1

Re: [PATCH 00/51] rtc: stop using rtc deprecated functions

[Alexandre Belloni]

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

Re: [PATCH 00/51] rtc: stop using rtc deprecated functions

[Alexandre Belloni]

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.

Re: [PATCH 00/51] rtc: stop using rtc deprecated functions

[Pavel Machek]

[-- 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 --]

Re: [PATCH 00/51] rtc: stop using rtc deprecated functions

[Alexandre Belloni]

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

Re: [PATCH 00/51] rtc: stop using rtc deprecated functions

[Pavel Machek]

[-- 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 --]

RE: [PATCH 00/51] rtc: stop using rtc deprecated functions

[Steve Twiss]

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.

Re: [PATCH 00/51] rtc: stop using rtc deprecated functions

[Pavel Machek]

[-- 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 --]

Re: [PATCH 00/51] rtc: stop using rtc deprecated functions

[Alexandre Belloni]

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

Re: [PATCH 00/51] rtc: stop using rtc deprecated functions

[Benjamin Gaignard]

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.

Re: [PATCH 00/51] rtc: stop using rtc deprecated functions

[Russell King - ARM Linux]

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.

Re: [PATCH 00/51] rtc: stop using rtc deprecated functions

[Pavel Machek]

[-- 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 --]

Re: [PATCH 00/51] rtc: stop using rtc deprecated functions

[Benjamin Gaignard]

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

RE: [PATCH 00/51] rtc: stop using rtc deprecated functions

[David Laight]

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.

Re: [PATCH 00/51] rtc: stop using rtc deprecated functions

[Russell King - ARM Linux]

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.