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 goo
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)
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
> > >
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
On Wed, Jun 21, 2017 at 09:26:51AM +, 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
> > 0x8000 secon
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
> 0x8000 seconds, we'll define the lower 0x4000 seconds to mean
> dates in the futur
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,
2017-06-21 0:08 GMT+02:00 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,
>
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
> > > (ap
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")
>
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
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 sen
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
> > > :
> > > >> Yes, that's argument against changing rtc _driv
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
> > :
> > >> Yes, that's argument against changing rtc _drivers_ for hardware that
> > >> can not do better than 32b
On Tue, Jun 20, 2017 at 05:07:46PM +0200, Benjamin Gaignard wrote:
> 2017-06-20 15:48 GMT+02:00 Alexandre Belloni
> :
> >> 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 ch
2017-06-20 15:48 GMT+02:00 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:
>> >
>> > >
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 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/
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,
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 t
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 bre
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 fa
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 t
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
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 callba
25 matches
Mail list logo
