[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 at lists.sourceforge.net
CC: Alessandro Zummo <a.zummo@towertech.it>
CC: Alexandre Belloni <alexandre.belloni@free-electrons.com>
CC: Gregory Clement <gregory.clement@free-electrons.com>
CC: Ingo Molnar <mingo@redhat.com>
CC: Jason Cooper <jason@lakedaemon.net>
CC: John Stultz <john.stultz@linaro.org>
CC: linux-arm-kernel at lists.infradead.org
CC: linux-kernel at vger.kernel.org
CC: Linus Walleij <linus.walleij@linaro.org>
CC: Michael Chan <michael.chan@broadcom.com>
CC: netdev at vger.kernel.org
CC: rtc-linux at googlegroups.com
CC: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
CC: Support Opensource <support.opensource@diasemi.com>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: x86 at kernel.org
CC: Baruch Siach <baruch@tkos.co.il>
CC: Hans Ulli Kroll <ulli.kroll@googlemail.com>
CC: Vladimir Zapolskiy <vz@mleia.com>
CC: Sylvain Lemieux <slemieux.tyco@gmail.com>
CC: Barry Song <baohua@kernel.org>
CC: Maxime Ripard <maxime.ripard@free-electrons.com>
CC: Chen-Yu Tsai <wens@csie.org>
CC: Thierry Reding <thierry.reding@gmail.com>
CC: Jonathan Hunter <jonathanh@nvidia.com>
CC: linux-tegra at vger.kernel.org
CC: patches at opensource.wolfsonmicro.com
CC: "Rafael J. Wysocki" <rjw@rjwysocki.net>
CC: Pavel Machek <pavel@ucw.cz>
CC: Len Brown <len.brown@intel.com>
CC: linux-pm at vger.kernel.org

1.9.1

[PATCH 07/51] rtc: ab8500: 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: Linus Walleij <linus.walleij@linaro.org>
CC: Alessandro Zummo <a.zummo@towertech.it>
CC: Alexandre Belloni <alexandre.belloni@free-electrons.com>
CC: rtc-linux at googlegroups.com
CC: linux-kernel at vger.kernel.org
CC: linux-arm-kernel at lists.infradead.org
---
 drivers/rtc/rtc-ab8500.c | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/rtc/rtc-ab8500.c b/drivers/rtc/rtc-ab8500.c
index 24a0af6..ac131bd 100644
--- a/drivers/rtc/rtc-ab8500.c
+++ b/drivers/rtc/rtc-ab8500.c
@@ -71,7 +71,7 @@
 /* Calculate the seconds from 1970 to 01-01-2000 00:00:00 */
 static unsigned long get_elapsed_seconds(int year)
 {
-	unsigned long secs;
+	unsigned long long secs;
 	struct rtc_time tm = {
 		.tm_year = year - 1900,
 		.tm_mday = 1,
@@ -81,7 +81,7 @@ static unsigned long get_elapsed_seconds(int year)
 	 * This function calculates secs from 1970 and not from
 	 * 1900, even if we supply the offset from year 1900.
 	 */
-	rtc_tm_to_time(&tm, &secs);
+	secs = rtc_tm_to_time64(&tm);
 	return secs;
 }
 
@@ -89,7 +89,7 @@ static int ab8500_rtc_read_time(struct device *dev, struct rtc_time *tm)
 {
 	unsigned long timeout = jiffies + HZ;
 	int retval, i;
-	unsigned long mins, secs;
+	unsigned long long mins, secs;
 	unsigned char buf[ARRAY_SIZE(ab8500_rtc_time_regs)];
 	u8 value;
 
@@ -130,7 +130,7 @@ static int ab8500_rtc_read_time(struct device *dev, struct rtc_time *tm)
 	/* Add back the initially subtracted number of seconds */
 	secs += get_elapsed_seconds(AB8500_RTC_EPOCH);
 
-	rtc_time_to_tm(secs, tm);
+	rtc_time64_to_tm(secs, tm);
 	return rtc_valid_tm(tm);
 }
 
@@ -138,7 +138,7 @@ static int ab8500_rtc_set_time(struct device *dev, struct rtc_time *tm)
 {
 	int retval, i;
 	unsigned char buf[ARRAY_SIZE(ab8500_rtc_time_regs)];
-	unsigned long no_secs, no_mins, secs = 0;
+	unsigned long long no_secs, no_mins, secs = 0;
 
 	if (tm->tm_year < (AB8500_RTC_EPOCH - 1900)) {
 		dev_dbg(dev, "year should be equal to or greater than %d\n",
@@ -147,7 +147,7 @@ static int ab8500_rtc_set_time(struct device *dev, struct rtc_time *tm)
 	}
 
 	/* Get the number of seconds since 1970 */
-	rtc_tm_to_time(tm, &secs);
+	secs = rtc_tm_to_time64(tm);
 
 	/*
 	 * Convert it to the number of seconds since 01-01-2000 00:00:00, since
@@ -185,7 +185,7 @@ static int ab8500_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alarm)
 	int retval, i;
 	u8 rtc_ctrl, value;
 	unsigned char buf[ARRAY_SIZE(ab8500_rtc_alarm_regs)];
-	unsigned long secs, mins;
+	unsigned long long secs, mins;
 
 	/* Check if the alarm is enabled or not */
 	retval = abx500_get_register_interruptible(dev, AB8500_RTC,
@@ -214,7 +214,7 @@ static int ab8500_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alarm)
 	/* Add back the initially subtracted number of seconds */
 	secs += get_elapsed_seconds(AB8500_RTC_EPOCH);
 
-	rtc_time_to_tm(secs, &alarm->time);
+	rtc_time64_to_tm(secs, &alarm->time);
 
 	return rtc_valid_tm(&alarm->time);
 }
@@ -230,7 +230,7 @@ static int ab8500_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alarm)
 {
 	int retval, i;
 	unsigned char buf[ARRAY_SIZE(ab8500_rtc_alarm_regs)];
-	unsigned long mins, secs = 0, cursec = 0;
+	unsigned long long mins, secs = 0, cursec = 0;
 	struct rtc_time curtm;
 
 	if (alarm->time.tm_year < (AB8500_RTC_EPOCH - 1900)) {
@@ -240,7 +240,7 @@ static int ab8500_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alarm)
 	}
 
 	/* Get the number of seconds since 1970 */
-	rtc_tm_to_time(&alarm->time, &secs);
+	secs = rtc_tm_to_time64(&alarm->time);
 
 	/*
 	 * Check whether alarm is set less than 1min.
@@ -248,7 +248,7 @@ static int ab8500_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alarm)
 	 * return -EINVAL, so UIE EMUL can take it up, incase of UIE_ON
 	 */
 	ab8500_rtc_read_time(dev, &curtm); /* Read current time */
-	rtc_tm_to_time(&curtm, &cursec);
+	cursec = rtc_tm_to_time64(&curtm);
 	if ((secs - cursec) < 59) {
 		dev_dbg(dev, "Alarm less than 1 minute not supported\r\n");
 		return -EINVAL;
@@ -281,7 +281,7 @@ static int ab8540_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alarm)
 {
 	int retval, i;
 	unsigned char buf[ARRAY_SIZE(ab8540_rtc_alarm_regs)];
-	unsigned long mins, secs = 0;
+	unsigned long long mins, secs = 0;
 
 	if (alarm->time.tm_year < (AB8500_RTC_EPOCH - 1900)) {
 		dev_dbg(dev, "year should be equal to or greater than %d\n",
@@ -290,7 +290,7 @@ static int ab8540_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alarm)
 	}
 
 	/* Get the number of seconds since 1970 */
-	rtc_tm_to_time(&alarm->time, &secs);
+	secs = rtc_tm_to_time64(&alarm->time);
 
 	/*
 	 * Convert it to the number of seconds since 01-01-2000 00:00:00
-- 
1.9.1

[PATCH 12/51] rtc: coh901331: 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: Linus Walleij <linus.walleij@linaro.org>
CC: Alessandro Zummo <a.zummo@towertech.it>
CC: Alexandre Belloni <alexandre.belloni@free-electrons.com>
CC: rtc-linux at googlegroups.com
CC: linux-kernel at vger.kernel.org
CC: linux-arm-kernel at 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)
 {
 	struct coh901331_port *rtap = dev_get_drvdata(dev);
 
@@ -104,7 +105,8 @@ static int coh901331_read_alarm(struct device *dev, struct rtc_wkalrm *alarm)
 	struct coh901331_port *rtap = dev_get_drvdata(dev);
 
 	clk_enable(rtap->clk);
-	rtc_time_to_tm(readl(rtap->virtbase + COH901331_ALARM), &alarm->time);
+	rtc_time64_to_tm(
+		(u64)readl(rtap->virtbase + COH901331_ALARM), &alarm->time);
 	alarm->pending = readl(rtap->virtbase + COH901331_IRQ_EVENT) & 1U;
 	alarm->enabled = readl(rtap->virtbase + COH901331_IRQ_MASK) & 1U;
 	clk_disable(rtap->clk);
@@ -115,9 +117,9 @@ static int coh901331_read_alarm(struct device *dev, struct rtc_wkalrm *alarm)
 static int coh901331_set_alarm(struct device *dev, struct rtc_wkalrm *alarm)
 {
 	struct coh901331_port *rtap = dev_get_drvdata(dev);
-	unsigned long time;
+	unsigned long long time;
 
-	rtc_tm_to_time(&alarm->time, &time);
+	time = rtc_tm_to_time64(&alarm->time);
 	clk_enable(rtap->clk);
 	writel(time, rtap->virtbase + COH901331_ALARM);
 	writel(alarm->enabled, rtap->virtbase + COH901331_IRQ_MASK);
@@ -142,7 +144,7 @@ static int coh901331_alarm_irq_enable(struct device *dev, unsigned int enabled)
 
 static const struct rtc_class_ops coh901331_ops = {
 	.read_time = coh901331_read_time,
-	.set_mmss = coh901331_set_mmss,
+	.set_mmss64 = coh901331_set_mmss64,
 	.read_alarm = coh901331_read_alarm,
 	.set_alarm = coh901331_set_alarm,
 	.alarm_irq_enable = coh901331_alarm_irq_enable,
-- 
1.9.1

[PATCH 17/51] rtc: digicolor: 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: Baruch Siach <baruch@tkos.co.il>
CC: Alessandro Zummo <a.zummo@towertech.it>
CC: Alexandre Belloni <alexandre.belloni@free-electrons.com>
CC: rtc-linux at googlegroups.com
CC: linux-kernel at vger.kernel.org
CC: linux-arm-kernel at lists.infradead.org
---
 drivers/rtc/rtc-digicolor.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-digicolor.c b/drivers/rtc/rtc-digicolor.c
index b253bf1..01b0fe8 100644
--- a/drivers/rtc/rtc-digicolor.c
+++ b/drivers/rtc/rtc-digicolor.c
@@ -106,7 +106,7 @@ static int dc_rtc_read_time(struct device *dev, struct rtc_time *tm)
 	return 0;
 }
 
-static int dc_rtc_set_mmss(struct device *dev, unsigned long secs)
+static int dc_rtc_set_mmss64(struct device *dev, time64_t secs)
 {
 	struct dc_rtc *rtc = dev_get_drvdata(dev);
 
@@ -161,7 +161,7 @@ static int dc_rtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
 
 static const struct rtc_class_ops dc_rtc_ops = {
 	.read_time		= dc_rtc_read_time,
-	.set_mmss		= dc_rtc_set_mmss,
+	.set_mmss64		= dc_rtc_set_mmss64,
 	.read_alarm		= dc_rtc_read_alarm,
 	.set_alarm		= dc_rtc_set_alarm,
 	.alarm_irq_enable	= dc_rtc_alarm_irq_enable,
-- 
1.9.1

[PATCH 26/51] rtc: gemini: 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: Hans Ulli Kroll <ulli.kroll@googlemail.com>
CC: Alessandro Zummo <a.zummo@towertech.it>
CC: Alexandre Belloni <alexandre.belloni@free-electrons.com>
CC: rtc-linux at googlegroups.com
CC: linux-kernel at vger.kernel.org
CC: linux-arm-kernel at lists.infradead.org
---
 drivers/rtc/rtc-gemini.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/rtc/rtc-gemini.c b/drivers/rtc/rtc-gemini.c
index 5279390..222f144 100644
--- a/drivers/rtc/rtc-gemini.c
+++ b/drivers/rtc/rtc-gemini.c
@@ -71,7 +71,7 @@ static int gemini_rtc_read_time(struct device *dev, struct rtc_time *tm)
 	struct gemini_rtc *rtc = dev_get_drvdata(dev);
 
 	unsigned int  days, hour, min, sec;
-	unsigned long offset, time;
+	unsigned long long offset, time;
 
 	sec  = readl(rtc->rtc_base + GEMINI_RTC_SECOND);
 	min  = readl(rtc->rtc_base + GEMINI_RTC_MINUTE);
@@ -81,7 +81,7 @@ static int gemini_rtc_read_time(struct device *dev, struct rtc_time *tm)
 
 	time = offset + days * 86400 + hour * 3600 + min * 60 + sec;
 
-	rtc_time_to_tm(time, tm);
+	rtc_time64_to_tm(time, tm);
 
 	return 0;
 }
@@ -90,12 +90,12 @@ static int gemini_rtc_set_time(struct device *dev, struct rtc_time *tm)
 {
 	struct gemini_rtc *rtc = dev_get_drvdata(dev);
 	unsigned int sec, min, hour, day;
-	unsigned long offset, time;
+	unsigned long long offset, time;
 
 	if (tm->tm_year >= 2148)	/* EPOCH Year + 179 */
 		return -EINVAL;
 
-	rtc_tm_to_time(tm, &time);
+	time = rtc_tm_to_time64(tm);
 
 	sec = readl(rtc->rtc_base + GEMINI_RTC_SECOND);
 	min = readl(rtc->rtc_base + GEMINI_RTC_MINUTE);
-- 
1.9.1

[PATCH 29/51] rtc: lpc32xx: 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.

For the same reasons use set_mmss64 callback instead of set_mmss

Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
CC: Vladimir Zapolskiy <vz@mleia.com>
CC: Sylvain Lemieux <slemieux.tyco@gmail.com>
CC: Alessandro Zummo <a.zummo@towertech.it>
CC: Alexandre Belloni <alexandre.belloni@free-electrons.com>
CC: rtc-linux at googlegroups.com
CC: linux-kernel at vger.kernel.org
CC: linux-arm-kernel at lists.infradead.org
---
 drivers/rtc/rtc-lpc32xx.c | 19 +++++++------------
 1 file changed, 7 insertions(+), 12 deletions(-)

diff --git a/drivers/rtc/rtc-lpc32xx.c b/drivers/rtc/rtc-lpc32xx.c
index 887871c..a3f5233 100644
--- a/drivers/rtc/rtc-lpc32xx.c
+++ b/drivers/rtc/rtc-lpc32xx.c
@@ -64,16 +64,16 @@ struct lpc32xx_rtc {
 
 static int lpc32xx_rtc_read_time(struct device *dev, struct rtc_time *time)
 {
-	unsigned long elapsed_sec;
+	unsigned long long elapsed_sec;
 	struct lpc32xx_rtc *rtc = dev_get_drvdata(dev);
 
 	elapsed_sec = rtc_readl(rtc, LPC32XX_RTC_UCOUNT);
-	rtc_time_to_tm(elapsed_sec, time);
+	rtc_time64_to_tm(elapsed_sec, time);
 
 	return rtc_valid_tm(time);
 }
 
-static int lpc32xx_rtc_set_mmss(struct device *dev, unsigned long secs)
+static int lpc32xx_rtc_set_mmss64(struct device *dev, time64_t secs)
 {
 	struct lpc32xx_rtc *rtc = dev_get_drvdata(dev);
 	u32 tmp;
@@ -97,7 +97,7 @@ static int lpc32xx_rtc_read_alarm(struct device *dev,
 {
 	struct lpc32xx_rtc *rtc = dev_get_drvdata(dev);
 
-	rtc_time_to_tm(rtc_readl(rtc, LPC32XX_RTC_MATCH0), &wkalrm->time);
+	rtc_time64_to_tm(rtc_readl(rtc, LPC32XX_RTC_MATCH0), &wkalrm->time);
 	wkalrm->enabled = rtc->alarm_enabled;
 	wkalrm->pending = !!(rtc_readl(rtc, LPC32XX_RTC_INTSTAT) &
 		LPC32XX_RTC_INTSTAT_MATCH0);
@@ -109,15 +109,10 @@ static int lpc32xx_rtc_set_alarm(struct device *dev,
 	struct rtc_wkalrm *wkalrm)
 {
 	struct lpc32xx_rtc *rtc = dev_get_drvdata(dev);
-	unsigned long alarmsecs;
+	unsigned long long alarmsecs;
 	u32 tmp;
-	int ret;
 
-	ret = rtc_tm_to_time(&wkalrm->time, &alarmsecs);
-	if (ret < 0) {
-		dev_warn(dev, "Failed to convert time: %d\n", ret);
-		return ret;
-	}
+	alarmsecs = rtc_tm_to_time64(&wkalrm->time);
 
 	spin_lock_irq(&rtc->lock);
 
@@ -191,7 +186,7 @@ static irqreturn_t lpc32xx_rtc_alarm_interrupt(int irq, void *dev)
 
 static const struct rtc_class_ops lpc32xx_rtc_ops = {
 	.read_time		= lpc32xx_rtc_read_time,
-	.set_mmss		= lpc32xx_rtc_set_mmss,
+	.set_mmss64		= lpc32xx_rtc_set_mmss64,
 	.read_alarm		= lpc32xx_rtc_read_alarm,
 	.set_alarm		= lpc32xx_rtc_set_alarm,
 	.alarm_irq_enable	= lpc32xx_rtc_alarm_irq_enable,
-- 
1.9.1

[PATCH 34/51] rtc: pl031: 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: Linus Walleij <linus.walleij@linaro.org>
CC: Alessandro Zummo <a.zummo@towertech.it>
CC: Alexandre Belloni <alexandre.belloni@free-electrons.com>
CC: rtc-linux at googlegroups.com
CC: linux-kernel at vger.kernel.org
CC: linux-arm-kernel at lists.infradead.org
---
 drivers/rtc/rtc-pl031.c | 31 +++++++++++++------------------
 1 file changed, 13 insertions(+), 18 deletions(-)

diff --git a/drivers/rtc/rtc-pl031.c b/drivers/rtc/rtc-pl031.c
index e1687e1..07f72b3 100644
--- a/drivers/rtc/rtc-pl031.c
+++ b/drivers/rtc/rtc-pl031.c
@@ -127,11 +127,11 @@ static int pl031_stv2_tm_to_time(struct device *dev,
 		return -EINVAL;
 	} else if (wday == -1) {
 		/* wday is not provided, calculate it here */
-		unsigned long time;
+		unsigned long long time;
 		struct rtc_time calc_tm;
 
-		rtc_tm_to_time(tm, &time);
-		rtc_time_to_tm(time, &calc_tm);
+		time = rtc_tm_to_time64(tm);
+		rtc_time64_to_tm(time, &calc_tm);
 		wday = calc_tm.tm_wday;
 	}
 
@@ -252,30 +252,27 @@ static int pl031_read_time(struct device *dev, struct rtc_time *tm)
 {
 	struct pl031_local *ldata = dev_get_drvdata(dev);
 
-	rtc_time_to_tm(readl(ldata->base + RTC_DR), tm);
+	rtc_time64_to_tm(readl(ldata->base + RTC_DR), tm);
 
 	return 0;
 }
 
 static int pl031_set_time(struct device *dev, struct rtc_time *tm)
 {
-	unsigned long time;
+	unsigned long long time;
 	struct pl031_local *ldata = dev_get_drvdata(dev);
-	int ret;
-
-	ret = rtc_tm_to_time(tm, &time);
 
-	if (ret == 0)
-		writel(time, ldata->base + RTC_LR);
+	time = rtc_tm_to_time64(tm);
+	writel(time, ldata->base + RTC_LR);
 
-	return ret;
+	return 0;
 }
 
 static int pl031_read_alarm(struct device *dev, struct rtc_wkalrm *alarm)
 {
 	struct pl031_local *ldata = dev_get_drvdata(dev);
 
-	rtc_time_to_tm(readl(ldata->base + RTC_MR), &alarm->time);
+	rtc_time64_to_tm(readl(ldata->base + RTC_MR), &alarm->time);
 
 	alarm->pending = readl(ldata->base + RTC_RIS) & RTC_BIT_AI;
 	alarm->enabled = readl(ldata->base + RTC_IMSC) & RTC_BIT_AI;
@@ -286,17 +283,15 @@ static int pl031_read_alarm(struct device *dev, struct rtc_wkalrm *alarm)
 static int pl031_set_alarm(struct device *dev, struct rtc_wkalrm *alarm)
 {
 	struct pl031_local *ldata = dev_get_drvdata(dev);
-	unsigned long time;
+	unsigned long long time;
 	int ret;
 
 	/* At the moment, we can only deal with non-wildcarded alarm times. */
 	ret = rtc_valid_tm(&alarm->time);
 	if (ret == 0) {
-		ret = rtc_tm_to_time(&alarm->time, &time);
-		if (ret == 0) {
-			writel(time, ldata->base + RTC_MR);
-			pl031_alarm_irq_enable(dev, alarm->enabled);
-		}
+		time = rtc_tm_to_time64(&alarm->time);
+		writel(time, ldata->base + RTC_MR);
+		pl031_alarm_irq_enable(dev, alarm->enabled);
 	}
 
 	return ret;
-- 
1.9.1

[PATCH 39/51] rtc: sirfsoc: 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: Alessandro Zummo <a.zummo@towertech.it>
CC: Alexandre Belloni <alexandre.belloni@free-electrons.com>
CC: Barry Song <baohua@kernel.org>
CC: rtc-linux at googlegroups.com
CC: linux-kernel at vger.kernel.org
CC: linux-arm-kernel at lists.infradead.org
---
 drivers/rtc/rtc-sirfsoc.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/rtc/rtc-sirfsoc.c b/drivers/rtc/rtc-sirfsoc.c
index 7367f61..972ede9 100644
--- a/drivers/rtc/rtc-sirfsoc.c
+++ b/drivers/rtc/rtc-sirfsoc.c
@@ -91,11 +91,11 @@ static int sirfsoc_rtc_read_alarm(struct device *dev,
 	 */
 	/* if alarm is in next overflow cycle */
 	if (rtc_count > rtc_alarm)
-		rtc_time_to_tm((rtcdrv->overflow_rtc + 1)
-				<< (BITS_PER_LONG - RTC_SHIFT)
-				| rtc_alarm >> RTC_SHIFT, &(alrm->time));
+		rtc_time64_to_tm((rtcdrv->overflow_rtc + 1)
+				  << (BITS_PER_LONG - RTC_SHIFT)
+				  | rtc_alarm >> RTC_SHIFT, &(alrm->time));
 	else
-		rtc_time_to_tm(rtcdrv->overflow_rtc
+		rtc_time64_to_tm(rtcdrv->overflow_rtc
 				<< (BITS_PER_LONG - RTC_SHIFT)
 				| rtc_alarm >> RTC_SHIFT, &(alrm->time));
 	if (sirfsoc_rtc_readl(rtcdrv, RTC_STATUS) & SIRFSOC_RTC_AL0E)
@@ -109,12 +109,12 @@ static int sirfsoc_rtc_read_alarm(struct device *dev,
 static int sirfsoc_rtc_set_alarm(struct device *dev,
 		struct rtc_wkalrm *alrm)
 {
-	unsigned long rtc_status_reg, rtc_alarm;
+	unsigned long long rtc_status_reg, rtc_alarm;
 	struct sirfsoc_rtc_drv *rtcdrv;
 	rtcdrv = dev_get_drvdata(dev);
 
 	if (alrm->enabled) {
-		rtc_tm_to_time(&(alrm->time), &rtc_alarm);
+		rtc_alarm = rtc_tm_to_time64(&alrm->time);
 
 		spin_lock_irq(&rtcdrv->lock);
 
@@ -182,7 +182,7 @@ static int sirfsoc_rtc_read_time(struct device *dev,
 		cpu_relax();
 	} while (tmp_rtc != sirfsoc_rtc_readl(rtcdrv, RTC_CN));
 
-	rtc_time_to_tm(rtcdrv->overflow_rtc << (BITS_PER_LONG - RTC_SHIFT) |
+	rtc_time64_to_tm(rtcdrv->overflow_rtc << (BITS_PER_LONG - RTC_SHIFT) |
 					tmp_rtc >> RTC_SHIFT, tm);
 	return 0;
 }
@@ -190,11 +190,11 @@ static int sirfsoc_rtc_read_time(struct device *dev,
 static int sirfsoc_rtc_set_time(struct device *dev,
 		struct rtc_time *tm)
 {
-	unsigned long rtc_time;
+	unsigned long long rtc_time;
 	struct sirfsoc_rtc_drv *rtcdrv;
 	rtcdrv = dev_get_drvdata(dev);
 
-	rtc_tm_to_time(tm, &rtc_time);
+	rtc_time = rtc_tm_to_time64(tm);
 
 	rtcdrv->overflow_rtc = rtc_time >> (BITS_PER_LONG - RTC_SHIFT);
 
-- 
1.9.1

[PATCH 43/51] rtc: sun6i: 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: Maxime Ripard <maxime.ripard@free-electrons.com>
CC: Chen-Yu Tsai <wens@csie.org>
CC: Alessandro Zummo <a.zummo@towertech.it>
CC: Alexandre Belloni <alexandre.belloni@free-electrons.com>
CC: rtc-linux at googlegroups.com
CC: linux-kernel at vger.kernel.org
CC: linux-arm-kernel at lists.infradead.org
---
 drivers/rtc/rtc-sun6i.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index 39cbc12..9928f74 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -120,7 +120,7 @@ struct sun6i_rtc_dev {
 	struct device *dev;
 	void __iomem *base;
 	int irq;
-	unsigned long alarm;
+	unsigned long long alarm;
 
 	struct clk_hw hw;
 	struct clk_hw *int_osc;
@@ -342,7 +342,7 @@ static int sun6i_rtc_getalarm(struct device *dev, struct rtc_wkalrm *wkalrm)
 
 	wkalrm->enabled = !!(alrm_en & SUN6I_ALRM_EN_CNT_EN);
 	wkalrm->pending = !!(alrm_st & SUN6I_ALRM_EN_CNT_EN);
-	rtc_time_to_tm(chip->alarm, &wkalrm->time);
+	rtc_time64_to_tm(chip->alarm, &wkalrm->time);
 
 	return 0;
 }
@@ -352,9 +352,9 @@ static int sun6i_rtc_setalarm(struct device *dev, struct rtc_wkalrm *wkalrm)
 	struct sun6i_rtc_dev *chip = dev_get_drvdata(dev);
 	struct rtc_time *alrm_tm = &wkalrm->time;
 	struct rtc_time tm_now;
-	unsigned long time_now = 0;
-	unsigned long time_set = 0;
-	unsigned long time_gap = 0;
+	unsigned long long time_now = 0;
+	unsigned long long time_set = 0;
+	unsigned long long time_gap = 0;
 	int ret = 0;
 
 	ret = sun6i_rtc_gettime(dev, &tm_now);
@@ -363,8 +363,8 @@ static int sun6i_rtc_setalarm(struct device *dev, struct rtc_wkalrm *wkalrm)
 		return -EINVAL;
 	}
 
-	rtc_tm_to_time(alrm_tm, &time_set);
-	rtc_tm_to_time(&tm_now, &time_now);
+	time_set = rtc_tm_to_time64(alrm_tm);
+	time_now = rtc_tm_to_time64(&tm_now);
 	if (time_set <= time_now) {
 		dev_err(dev, "Date to set in the past\n");
 		return -EINVAL;
-- 
1.9.1

[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 at lists.sourceforge.net
> CC: Alessandro Zummo <a.zummo@towertech.it>
> CC: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> CC: Gregory Clement <gregory.clement@free-electrons.com>
> CC: Ingo Molnar <mingo@redhat.com>
> CC: Jason Cooper <jason@lakedaemon.net>
> CC: John Stultz <john.stultz@linaro.org>
> CC: linux-arm-kernel at lists.infradead.org
> CC: linux-kernel at vger.kernel.org
> CC: Linus Walleij <linus.walleij@linaro.org>
> CC: Michael Chan <michael.chan@broadcom.com>
> CC: netdev at vger.kernel.org
> CC: rtc-linux at googlegroups.com
> CC: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> CC: Support Opensource <support.opensource@diasemi.com>
> CC: Thomas Gleixner <tglx@linutronix.de>
> CC: x86 at kernel.org
> CC: Baruch Siach <baruch@tkos.co.il>
> CC: Hans Ulli Kroll <ulli.kroll@googlemail.com>
> CC: Vladimir Zapolskiy <vz@mleia.com>
> CC: Sylvain Lemieux <slemieux.tyco@gmail.com>
> CC: Barry Song <baohua@kernel.org>
> CC: Maxime Ripard <maxime.ripard@free-electrons.com>
> CC: Chen-Yu Tsai <wens@csie.org>
> CC: Thierry Reding <thierry.reding@gmail.com>
> CC: Jonathan Hunter <jonathanh@nvidia.com>
> CC: linux-tegra at vger.kernel.org
> CC: patches at opensource.wolfsonmicro.com
> CC: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> CC: Pavel Machek <pavel@ucw.cz>
> CC: Len Brown <len.brown@intel.com>
> CC: linux-pm at vger.kernel.org
> 
> 1.9.1
> 

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[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 at lists.sourceforge.net
> > CC: Alessandro Zummo <a.zummo@towertech.it>
> > CC: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> > CC: Gregory Clement <gregory.clement@free-electrons.com>
> > CC: Ingo Molnar <mingo@redhat.com>
> > CC: Jason Cooper <jason@lakedaemon.net>
> > CC: John Stultz <john.stultz@linaro.org>
> > CC: linux-arm-kernel at lists.infradead.org
> > CC: linux-kernel at vger.kernel.org
> > CC: Linus Walleij <linus.walleij@linaro.org>
> > CC: Michael Chan <michael.chan@broadcom.com>
> > CC: netdev at vger.kernel.org
> > CC: rtc-linux at googlegroups.com
> > CC: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> > CC: Support Opensource <support.opensource@diasemi.com>
> > CC: Thomas Gleixner <tglx@linutronix.de>
> > CC: x86 at kernel.org
> > CC: Baruch Siach <baruch@tkos.co.il>
> > CC: Hans Ulli Kroll <ulli.kroll@googlemail.com>
> > CC: Vladimir Zapolskiy <vz@mleia.com>
> > CC: Sylvain Lemieux <slemieux.tyco@gmail.com>
> > CC: Barry Song <baohua@kernel.org>
> > CC: Maxime Ripard <maxime.ripard@free-electrons.com>
> > CC: Chen-Yu Tsai <wens@csie.org>
> > CC: Thierry Reding <thierry.reding@gmail.com>
> > CC: Jonathan Hunter <jonathanh@nvidia.com>
> > CC: linux-tegra at vger.kernel.org
> > CC: patches at opensource.wolfsonmicro.com
> > CC: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> > CC: Pavel Machek <pavel@ucw.cz>
> > CC: Len Brown <len.brown@intel.com>
> > CC: linux-pm at vger.kernel.org
> > 
> > 1.9.1
> > 
> 
> -- 
> Alexandre Belloni, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[Pavel Machek]

On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote:
> On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote:
> > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
> > rely on 32bits variables and that will make rtc break in y2038/2016.
> 
> Please don't, because this hide the fact that the hardware will not
> handle dates in y2038 anyway and as pointed by Russell a few month ago,
> rtc_time_to_tm will be able to catch it but the 64 bit version will
> silently ignore it.

Reference? Because rtc on PCs stores date in binary coded decimal, so
it is likely to break in 2100, not 2038...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170620/429aeb11/attachment.sig>

[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

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

[Pavel Machek]

On Tue 2017-06-20 14:24:00, Alexandre Belloni wrote:
> On 20/06/2017 at 14:10:11 +0200, Pavel Machek wrote:
> > On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote:
> > > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote:
> > > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
> > > > rely on 32bits variables and that will make rtc break in y2038/2016.
> > > 
> > > Please don't, because this hide the fact that the hardware will not
> > > handle dates in y2038 anyway and as pointed by Russell a few month ago,
> > > rtc_time_to_tm will be able to catch it but the 64 bit version will
> > > silently ignore it.
> > 
> > Reference? Because rtc on PCs stores date in binary coded decimal, so
> > it is likely to break in 2100, not 2038...
> 
> I'm not saying it should be done but clearly, that is not the correct
> thing to do for RTCs that are using a single 32 bits register to store
> the time.
> You give one example, I can give you three: armada38x, at91sam9,
> at32ap700x and that just in the beginning of the series.

I wanted reference to Russell's mail.

> And yes, on PC, they will break in 2100, other in 2106, some in 2070.
> I've delayed the tree wide patching until I manage to finish reworking
> the infrastructure needed to handle the limits of the RTCs.

Kernel does not know if it has working RTC or not, so it should use
64bit variables. Merging this -- does not hide anything. Yes, some
drivers still may have problems -- so we fix the drivers.

You said:

> > > rtc_time_to_tm will be able to catch it but the 64 bit will
> > > silently ignore it.

If that's the case, we may need 64bit version to be smarter.. but
we'll still need 64bit variables in the kernel.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170620/a572ef17/attachment.sig>

[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

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

[Pavel Machek]

On Tue 2017-06-20 13:37:22, Steve Twiss wrote:
> Hi Pavel,
> 
> On 20 June 2017 14:26, Pavel Machek wrote:
> 
> > Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions
> > 
> > On Tue 2017-06-20 14:24:00, Alexandre Belloni wrote:
> > > On 20/06/2017 at 14:10:11 +0200, Pavel Machek wrote:
> > > > On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote:
> > > > > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote:
> > > > > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
> > > > > > rely on 32bits variables and that will make rtc break in y2038/2016.
> > > > >
> > > > > Please don't, because this hide the fact that the hardware will not
> > > > > handle dates in y2038 anyway and as pointed by Russell a few month ago,
> > > > > rtc_time_to_tm will be able to catch it but the 64 bit version will
> > > > > silently ignore it.
> > > >
> > > > Reference? Because rtc on PCs stores date in binary coded decimal, so
> > > > it is likely to break in 2100, not 2038...
> > >
> > > I'm not saying it should be done but clearly, that is not the correct
> > > thing to do for RTCs that are using a single 32 bits register to store
> > > the time.
> > > You give one example, I can give you three: armada38x, at91sam9,
> > > at32ap700x and that just in the beginning of the series.
> > 
> > I wanted reference to Russell's mail.
> 
> This is it.
> https://patchwork.kernel.org/patch/6219401/

Thanks.

Yes, that's argument against changing rtc _drivers_ for hardware that
can not do better than 32bit. For generic code (such as 44/51 sysfs,
51/51 suspend test), the change still makes sense.

								Pavel

-- (english)
http://www.livejournal.com/~pavelmachek (cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170620/c1b740ae/attachment.sig>

[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

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

[Benjamin Gaignard]

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

[PATCH 07/51] rtc: ab8500: stop using rtc deprecated functions

[Linus Walleij]

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 at googlegroups.com
> CC: linux-kernel at vger.kernel.org
> CC: linux-arm-kernel at lists.infradead.org

Looks fine.
Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

[rtc-linux] [PATCH 12/51] rtc: coh901331: stop using rtc deprecated functions

[Linus Walleij]

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 at googlegroups.com
> CC: linux-kernel at vger.kernel.org
> CC: linux-arm-kernel at lists.infradead.org

Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

[PATCH 34/51] rtc: pl031: stop using rtc deprecated functions

[Linus Walleij]

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 at googlegroups.com
> CC: linux-kernel at vger.kernel.org
> CC: linux-arm-kernel at lists.infradead.org

Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

[PATCH 34/51] rtc: pl031: stop using rtc deprecated functions

[Russell King - ARM Linux]

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 at googlegroups.com
> > CC: linux-kernel at vger.kernel.org
> > CC: linux-arm-kernel at 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.

[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@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.

[PATCH 12/51] rtc: coh901331: stop using rtc deprecated functions

[Russell King - ARM Linux]

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 at googlegroups.com
> CC: linux-kernel at vger.kernel.org
> CC: linux-arm-kernel at 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.

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

[Thomas Gleixner]

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

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

[Pavel Machek]

Hi!

> >> > This is it.
> >> > https://patchwork.kernel.org/patch/6219401/
> >>
> >> Thanks.
> >>
> >> Yes, that's argument against changing rtc _drivers_ for hardware that
> >> can not do better than 32bit. For generic code (such as 44/51 sysfs,
> >> 51/51 suspend test), the change still makes sense.
> 
> What I had in mind when writing those patches was to remove the limitations
> coming from those functions usage, even more since they been marked has
> deprecated.
> 
> I agree that will change nothing of hardware limitation but at least
> the limit will
> not come from the framework.

> > Yes, we agree on that but I won't cherry pick working patches from a 51
> > patches series.

Well, it would be actually nice for you to do the cherry
picking. That's something maintainers do, because it is hard for
contributors to guess maintainer's taste.

Anyway, it looks like someone should go through all the RTC drivers,
and document their limitations of each driver (date in future when
hardware ceases to be useful). If Benjamin has time to do that, I
guess that removes all the objections to the series.

Regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170621/9ea489d7/attachment-0001.sig>

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

[Russell King - ARM Linux]

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.

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

[Pavel Machek]

Hi!

> > > > I think tglx had a plan for offsetting the time at some point so 32-bit
> > > > platform can pass 2038 properly.
> > > 
> > > Yes, but there are still quite some issues to solve there:
> > > 
> > >      1) How do you tell the system that it should apply the offset in the
> > >      	first place, i.e at boot time before NTP or any other mechanism can
> > >      	correct it?
> > 
> > I'd not do offset. Instead, I'd select a threshold (perhaps year of
> > release of given kernel?) and
> > 
> > 	if (rtc_time < year_of_release_of_kernel)
> > 	   rtc_time += 0x100000000;
> > 
> > Ok, we'll have to move away from "rtc_time == 0 indicates zero", as
> > seen in some drivers.
> > 
> > >      2) Deal with creative vendors who have their own idea about the 'start
> > >      	of the epoch'
> > 
> > If someone uses different threshold, well, there will be
> > confusion. But only for users that have their rtc set to the past,
> > which is quite unusual.
> > 
> 
> Or not, having an RTC set in the past is actually quite common. I'd find
> it weird to have a new device boot and be set to a date in the future.

...but still better than board stuck in the past, no?

> Also note that the threshold or offset thing may seem like a good idea
> but fails with many RTCs because of how they handle leap years.

Well, you can still convert time from rtc to unix time, then do adjustment
there.

Anyway, I guess it would be cool for rtc drivers to annotate what limits
underlying storage has to the common code, so that we can do fixups once
per class, not once per driver.
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH 07/51] rtc: ab8500: stop using rtc deprecated functions

[kbuild test robot]

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-u8500_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 `ab8540_rtc_set_alarm':
>> drivers/rtc/rtc-ab8500.c:299: undefined reference to `__aeabi_uldivmod'
   drivers/rtc/rtc-ab8500.c:301: undefined reference to `__aeabi_uldivmod'
   drivers/built-in.o: In function `ab8500_rtc_set_time':
   drivers/rtc/rtc-ab8500.c:158: undefined reference to `__aeabi_uldivmod'
   drivers/rtc/rtc-ab8500.c:160: undefined reference to `__aeabi_uldivmod'
   drivers/built-in.o: In function `ab8500_rtc_set_alarm':
   drivers/rtc/rtc-ab8500.c:263: undefined reference to `__aeabi_uldivmod'

vim +299 drivers/rtc/rtc-ab8500.c

45a9f91a Benjamin Gaignard 2017-06-20  293  	secs = rtc_tm_to_time64(&alarm->time);
25d053cf Alexandre Torgue  2013-07-03  294  
25d053cf Alexandre Torgue  2013-07-03  295  	/*
25d053cf Alexandre Torgue  2013-07-03  296  	 * Convert it to the number of seconds since 01-01-2000 00:00:00
25d053cf Alexandre Torgue  2013-07-03  297  	 */
25d053cf Alexandre Torgue  2013-07-03  298  	secs -= get_elapsed_seconds(AB8500_RTC_EPOCH);
25d053cf Alexandre Torgue  2013-07-03 @299  	mins = secs / 60;
25d053cf Alexandre Torgue  2013-07-03  300  
25d053cf Alexandre Torgue  2013-07-03  301  	buf[3] = secs % 60;
25d053cf Alexandre Torgue  2013-07-03  302  	buf[2] = mins & 0xFF;

:::::: The code at line 299 was first introduced by commit
:::::: 25d053cf1040e6430fff679854b3710edb0b7fee drivers/rtc/rtc-ab8500.c: add second resolution to rtc driver

:::::: TO: Alexandre Torgue <alexandre.torgue@st.com>
:::::: CC: Linus Torvalds <torvalds@linux-foundation.org>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 22400 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170621/a1528dd6/attachment-0001.gz>

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

[Pavel Machek]

Hi!

> > I agree with that but not the android guys. They seem to mandate an RTC
> > that can store time from 01/01/1970. I don't know much more than that
> > because they never cared to explain why that was actually necessary
> > (apart from a laconic "this will result in a bad user experience")
> > 
> > I think tglx had a plan for offsetting the time at some point so 32-bit
> > platform can pass 2038 properly.
> 
> Yes, but there are still quite some issues to solve there:
> 
>      1) How do you tell the system that it should apply the offset in the
>      	first place, i.e at boot time before NTP or any other mechanism can
>      	correct it?

I'd not do offset. Instead, I'd select a threshold (perhaps year of
release of given kernel?) and

	if (rtc_time < year_of_release_of_kernel)
	   rtc_time += 0x100000000;

Ok, we'll have to move away from "rtc_time == 0 indicates zero", as
seen in some drivers.

>      2) Deal with creative vendors who have their own idea about the 'start
>      	of the epoch'

If someone uses different threshold, well, there will be
confusion. But only for users that have their rtc set to the past,
which is quite unusual.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170621/7837e096/attachment-0001.sig>

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

[Alexandre Belloni]

On 21/06/2017 at 09:51:52 +0200, Pavel Machek wrote:
> Hi!
> 
> > > I agree with that but not the android guys. They seem to mandate an RTC
> > > that can store time from 01/01/1970. I don't know much more than that
> > > because they never cared to explain why that was actually necessary
> > > (apart from a laconic "this will result in a bad user experience")
> > > 
> > > I think tglx had a plan for offsetting the time at some point so 32-bit
> > > platform can pass 2038 properly.
> > 
> > Yes, but there are still quite some issues to solve there:
> > 
> >      1) How do you tell the system that it should apply the offset in the
> >      	first place, i.e at boot time before NTP or any other mechanism can
> >      	correct it?
> 
> I'd not do offset. Instead, I'd select a threshold (perhaps year of
> release of given kernel?) and
> 
> 	if (rtc_time < year_of_release_of_kernel)
> 	   rtc_time += 0x100000000;
> 
> Ok, we'll have to move away from "rtc_time == 0 indicates zero", as
> seen in some drivers.
> 
> >      2) Deal with creative vendors who have their own idea about the 'start
> >      	of the epoch'
> 
> If someone uses different threshold, well, there will be
> confusion. But only for users that have their rtc set to the past,
> which is quite unusual.
> 

Or not, having an RTC set in the past is actually quite common. I'd find
it weird to have a new device boot and be set to a date in the future.

Also note that the threshold or offset thing may seem like a good idea
but fails with many RTCs because of how they handle leap years.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[Benjamin Gaignard]

2017-06-21 0:08 GMT+02:00 Pavel Machek <pavel@ucw.cz>:
> Hi!
>
>> >> > This is it.
>> >> > https://patchwork.kernel.org/patch/6219401/
>> >>
>> >> Thanks.
>> >>
>> >> Yes, that's argument against changing rtc _drivers_ for hardware that
>> >> can not do better than 32bit. For generic code (such as 44/51 sysfs,
>> >> 51/51 suspend test), the change still makes sense.
>>
>> What I had in mind when writing those patches was to remove the limitations
>> coming from those functions usage, even more since they been marked has
>> deprecated.
>>
>> I agree that will change nothing of hardware limitation but at least
>> the limit will
>> not come from the framework.
>
>> > Yes, we agree on that but I won't cherry pick working patches from a 51
>> > patches series.
>
> Well, it would be actually nice for you to do the cherry
> picking. That's something maintainers do, because it is hard for
> contributors to guess maintainer's taste.
>
> Anyway, it looks like someone should go through all the RTC drivers,
> and document their limitations of each driver (date in future when
> hardware ceases to be useful). If Benjamin has time to do that, I
> guess that removes all the objections to the series.

Without the datasheet I can check in driver code what they do in read/set
time functions to understand their limitations. All drivers using BCD
like system
or spliting day and time should be fixed. I can do a subset of my patches
including those driver + the acked ones.

Alexandre does that sound reasonable for you ?


> Regards,
>                                                                         Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Russell King - ARM Linux]

On Wed, Jun 21, 2017 at 10:39:07AM +0200, Alexandre Belloni wrote:
> On 21/06/2017 at 09:51:52 +0200, Pavel Machek wrote:
> > If someone uses different threshold, well, there will be
> > confusion. But only for users that have their rtc set to the past,
> > which is quite unusual.
> > 
> 
> Or not, having an RTC set in the past is actually quite common. I'd find
> it weird to have a new device boot and be set to a date in the future.

... and that basically means you can't use hardware that stores RTC
time as a 32-bit number of seconds past 2106.

> Also note that the threshold or offset thing may seem like a good idea
> but fails with many RTCs because of how they handle leap years.

Not for the case being discussed.  A 32-bit counter of seconds knows
nothing about leap years - all that is handled by the conversion
functions.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[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

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

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

[Alexandre Belloni]

On 21/06/2017 at 10:19:49 +0100, Russell King - ARM Linux wrote:
> On Wed, Jun 21, 2017 at 10:39:07AM +0200, Alexandre Belloni wrote:
> > On 21/06/2017 at 09:51:52 +0200, Pavel Machek wrote:
> > > If someone uses different threshold, well, there will be
> > > confusion. But only for users that have their rtc set to the past,
> > > which is quite unusual.
> > > 
> > 
> > Or not, having an RTC set in the past is actually quite common. I'd find
> > it weird to have a new device boot and be set to a date in the future.
> 
> ... and that basically means you can't use hardware that stores RTC
> time as a 32-bit number of seconds past 2106.
> 

And I guess it will not matter much for us anyway ;)

> > Also note that the threshold or offset thing may seem like a good idea
> > but fails with many RTCs because of how they handle leap years.
> 
> Not for the case being discussed.  A 32-bit counter of seconds knows
> nothing about leap years - all that is handled by the conversion
> functions.
> 

Well, the patch series touches some RTCs that are not using 32 bit
counter so I though I might as well raise the issue now.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[Alexandre Belloni]

On 21/06/2017 at 08:34:43 +0200, Pavel Machek wrote:
> Hi!
> 
> > > > > I think tglx had a plan for offsetting the time at some point so 32-bit
> > > > > platform can pass 2038 properly.
> > > > 
> > > > Yes, but there are still quite some issues to solve there:
> > > > 
> > > >      1) How do you tell the system that it should apply the offset in the
> > > >      	first place, i.e at boot time before NTP or any other mechanism can
> > > >      	correct it?
> > > 
> > > I'd not do offset. Instead, I'd select a threshold (perhaps year of
> > > release of given kernel?) and
> > > 
> > > 	if (rtc_time < year_of_release_of_kernel)
> > > 	   rtc_time += 0x100000000;
> > > 
> > > Ok, we'll have to move away from "rtc_time == 0 indicates zero", as
> > > seen in some drivers.
> > > 
> > > >      2) Deal with creative vendors who have their own idea about the 'start
> > > >      	of the epoch'
> > > 
> > > If someone uses different threshold, well, there will be
> > > confusion. But only for users that have their rtc set to the past,
> > > which is quite unusual.
> > > 
> > 
> > Or not, having an RTC set in the past is actually quite common. I'd find
> > it weird to have a new device boot and be set to a date in the future.
> 
> ...but still better than board stuck in the past, no?
> 
> > Also note that the threshold or offset thing may seem like a good idea
> > but fails with many RTCs because of how they handle leap years.
> 
> Well, you can still convert time from rtc to unix time, then do adjustment
> there.
> 

You can only if your machine is running when that happens. If that is
not the case, then you lost and your time is not correct anymore.

There is currently one rtc doing that kind of trick but it is used as a
simple time counter from the beginning. Transitioning is the difficult
part.

> Anyway, I guess it would be cool for rtc drivers to annotate what limits
> underlying storage has to the common code, so that we can do fixups once
> per class, not once per driver.

Yes, I'm in the middle of the whole rework that allows that.

I don't understand the sudden urgency of fixing that and the amount of
bikeshedding, seeing that the closest cutoff date is actually 31st of
december 2069 in the rtc subsystem and that anyway the current 32bit
userspace will explode in february 2038.

My plan from the beginning was to have something for the next stable. I
know nobody can read my mind but again, I don't think there is currently
any urgency to change anything.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[Pavel Machek]

Hi!

> > > Or not, having an RTC set in the past is actually quite common. I'd find
> > > it weird to have a new device boot and be set to a date in the future.
> > 
> > ...but still better than board stuck in the past, no?
> > 
> > > Also note that the threshold or offset thing may seem like a good idea
> > > but fails with many RTCs because of how they handle leap years.
> > 
> > Well, you can still convert time from rtc to unix time, then do adjustment
> > there.
> > 
> 
> You can only if your machine is running when that happens. If that is
> not the case, then you lost and your time is not correct anymore.

I don't see why that should be a case... as long as you know what RTC
does in event of overflow, and it is not something completely crazy.

> > Anyway, I guess it would be cool for rtc drivers to annotate what limits
> > underlying storage has to the common code, so that we can do fixups once
> > per class, not once per driver.
> 
> Yes, I'm in the middle of the whole rework that allows that.
> 
> I don't understand the sudden urgency of fixing that and the amount of
> bikeshedding, seeing that the closest cutoff date is actually 31st of
> december 2069 in the rtc subsystem and that anyway the current 32bit
> userspace will explode in february 2038.
> 
> My plan from the beginning was to have something for the next stable. I
> know nobody can read my mind but again, I don't think there is currently
> any urgency to change anything.

Yes, mind reading is a problem. I can only read minds of ferungulates,
and only if they are physicaly near me :-).

Best regards,
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170621/cd332894/attachment.sig>