All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexandre Belloni <alexandre.belloni@free-electrons.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: pang.xunlei@zte.com.cn, Alessandro Zummo <a.zummo@towertech.it>,
	Andrew Christian <andrew.christian@hp.com>,
	CIH <cih@coventive.com>, John Stultz <john.stultz@linaro.org>,
	linux-kernel@vger.kernel.org, Nicolas Pitre <nico@fluxnic.net>,
	Xunlei Pang <pang.xunlei@linaro.org>,
	Richard Purdie <rpurdie@rpsys.net>,
	rtc-linux@googlegroups.com, Xunlei Pang <xlpang@126.com>
Subject: [rtc-linux] Re: [5/5] drivers/rtc/sa1100: Replace deprecated rtc_tm_to_time() and rtc_time_to_tm()
Date: Mon, 1 Jun 2015 21:59:09 +0200	[thread overview]
Message-ID: <20150601195909.GO4710@piout.net> (raw)
In-Reply-To: <3404495.679z0IaaBp@wuerfel>

Hi,

On 01/06/2015 at 21:43:22 +0200, Arnd Bergmann wrote :
> Note that Alexandre has stepped up as a new maintainer for RTC now,
> so whatever he wants is probably the way it should be done.
> 

I'm still quite new in that position and I didn't make my mind in a lot
of different topics ;)

> I think the way that your first approach came out was a bit unfortunate,
> because we didn't have agreement on how it should really be done.
> 
> IMHO the rtc_time64_to_hw32 and rtc_hw32_to_time64 interfaces were a
> good concept, most importantly so we can easily find where the potential
> problems are, but the implementation was a bit too ambitious in trying
> to fix the underlying issue.
> 
> If we want to start this over again, I think a better approach would be
> to introduce trivial functions at first, like
> 
> time64_t rtc_hw32_to_time64(u32 hwtime)
> {
> 	/* 
> 	 * this is safe until about 2106, when unsigned u32 seconds from the
> 	 * 1970 epoch will overflow
> 	 */
> 	return (u64)hwtime;
> }
> EXPORT_SYMBOL_GPL(rtc_hw32_to_time64);
> 
> This way, we can fix all the drivers without introducing any possible
> ambiguity and later decide how that function should in fact handle the
> 2106 overflow. Our grandchildren can take care of that if necessary ;-)
> 

We also have RTCs that can only store the year as an integer between 0
and 99. Some of them will definitively not pass 2099, considering that
the can only handle leap days between 2000 and 2099. Also, we have a few
drivers assuming that year >= 70 is in the 19s so they will stop working
correctly in 2070. I think we also have to consider those while trying
to find a solution.

I feel that we still have a bit of time before having to hurry and find
a proper solution ;)

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

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

WARNING: multiple messages have this Message-ID (diff)
From: Alexandre Belloni <alexandre.belloni@free-electrons.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: pang.xunlei@zte.com.cn, Alessandro Zummo <a.zummo@towertech.it>,
	Andrew Christian <andrew.christian@hp.com>,
	CIH <cih@coventive.com>, John Stultz <john.stultz@linaro.org>,
	linux-kernel@vger.kernel.org, Nicolas Pitre <nico@fluxnic.net>,
	Xunlei Pang <pang.xunlei@linaro.org>,
	Richard Purdie <rpurdie@rpsys.net>,
	rtc-linux@googlegroups.com, Xunlei Pang <xlpang@126.com>
Subject: Re: [5/5] drivers/rtc/sa1100: Replace deprecated rtc_tm_to_time() and rtc_time_to_tm()
Date: Mon, 1 Jun 2015 21:59:09 +0200	[thread overview]
Message-ID: <20150601195909.GO4710@piout.net> (raw)
In-Reply-To: <3404495.679z0IaaBp@wuerfel>

Hi,

On 01/06/2015 at 21:43:22 +0200, Arnd Bergmann wrote :
> Note that Alexandre has stepped up as a new maintainer for RTC now,
> so whatever he wants is probably the way it should be done.
> 

I'm still quite new in that position and I didn't make my mind in a lot
of different topics ;)

> I think the way that your first approach came out was a bit unfortunate,
> because we didn't have agreement on how it should really be done.
> 
> IMHO the rtc_time64_to_hw32 and rtc_hw32_to_time64 interfaces were a
> good concept, most importantly so we can easily find where the potential
> problems are, but the implementation was a bit too ambitious in trying
> to fix the underlying issue.
> 
> If we want to start this over again, I think a better approach would be
> to introduce trivial functions at first, like
> 
> time64_t rtc_hw32_to_time64(u32 hwtime)
> {
> 	/* 
> 	 * this is safe until about 2106, when unsigned u32 seconds from the
> 	 * 1970 epoch will overflow
> 	 */
> 	return (u64)hwtime;
> }
> EXPORT_SYMBOL_GPL(rtc_hw32_to_time64);
> 
> This way, we can fix all the drivers without introducing any possible
> ambiguity and later decide how that function should in fact handle the
> 2106 overflow. Our grandchildren can take care of that if necessary ;-)
> 

We also have RTCs that can only store the year as an integer between 0
and 99. Some of them will definitively not pass 2099, considering that
the can only handle leap days between 2000 and 2099. Also, we have a few
drivers assuming that year >= 70 is in the 19s so they will stop working
correctly in 2070. I think we also have to consider those while trying
to find a solution.

I feel that we still have a bit of time before having to hurry and find
a proper solution ;)

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

  reply	other threads:[~2015-06-01 19:59 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-15  9:20 [5/5] drivers/rtc/sa1100: Replace deprecated rtc_tm_to_time() and rtc_time_to_tm() Xunlei Pang
2015-04-15  9:20 ` [PATCH 5/5] " Xunlei Pang
2015-04-29 23:28 ` [5/5] " Alexandre Belloni
2015-05-29 14:32   ` [rtc-linux] " pang.xunlei
     [not found]   ` <OF1F6D43BC.C38481A0-ON48257E54.004FA90B-48257E54.004FD9D8@LocalDomain>
2015-05-30 10:05     ` pang.xunlei
2015-06-01 19:43       ` Arnd Bergmann
2015-06-01 19:43         ` Arnd Bergmann
2015-06-01 19:59         ` Alexandre Belloni [this message]
2015-06-01 19:59           ` Alexandre Belloni
2015-06-03 14:17           ` [rtc-linux] " Alessandro Zummo
2015-06-03 14:17             ` Alessandro Zummo
  -- strict thread matches above, loose matches on Subject: below --
2015-04-15  9:20 [3/5] drivers/rtc/sunxi: Replace deprecated rtc_tm_to_time() Xunlei Pang
2015-04-15  9:20 ` [PATCH 3/5] " Xunlei Pang
2015-04-15  9:20 [2/5] drivers/rtc/isl1208: " Xunlei Pang
2015-04-15  9:20 ` [PATCH 2/5] " Xunlei Pang
2015-04-15  9:20 [1/5] drivers/rtc/pcf8563: Replace deprecated rtc_time_to_tm() and rtc_tm_to_time() Xunlei Pang
2015-04-15  9:20 ` [PATCH 1/5] " Xunlei Pang
2015-04-15  9:20 ` [4/5] drivers/rtc/pl030: Replace deprecated rtc_tm_to_time() and rtc_time_to_tm() Xunlei Pang
2015-04-15  9:20   ` [PATCH 4/5] " Xunlei Pang
2015-04-15  9:35   ` [rtc-linux] " Russell King - ARM Linux
2015-04-15  9:35     ` Russell King - ARM Linux

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150601195909.GO4710@piout.net \
    --to=alexandre.belloni@free-electrons.com \
    --cc=a.zummo@towertech.it \
    --cc=andrew.christian@hp.com \
    --cc=arnd@arndb.de \
    --cc=cih@coventive.com \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nico@fluxnic.net \
    --cc=pang.xunlei@linaro.org \
    --cc=pang.xunlei@zte.com.cn \
    --cc=rpurdie@rpsys.net \
    --cc=rtc-linux@googlegroups.com \
    --cc=xlpang@126.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.