Re: rtc-palmas: correct for bcd year

[Mark Salyzyn]

On 01/04/2016 08:18 AM, Alexandre Belloni wrote:
> Hi,
>
> On 30/12/2015 at 12:51:45 -0800, Mark Salyzyn wrote :
> > Replace bcd2bin and bin2bcd with one that maps years 1970 to 2129
> > in a pattern that works with the underlying hardware.
> >
> > The only transition that does not work correctly for this rtc clock
> > is the transition from 2099 to 2100, it proceeds to 2000. The rtc
> > clock retains and transitions the year correctly in all other
> > circumstances.
> If that transition doesn't work, it is not useful to try to support
> dates after 2099. Also, I'm concerned about the leap year handling in
> the other case. What is done right now is probably the best however, I
> couldn't find the datasheet to confirm.

As it stands today, if I set the date to 1970, it returns 2066, so this 
is a leap(sic) forward for this one rtc clock.

The advantages of supporting 2099+ for being able to set those years and 
not return garbage like in the 1970 case. The failure to roll over from 
2099-2100 is but a millisecond of failure for an additional 1/3 of 
century of well being, and support code is minor, albeit flawed. Without 
these additional four lines, if something sets the year to 2100, they 
will get a garbage back in return, a small price to pay IMHO.

There are dozens and dozens of other bcd-based rtc clocks that could 
gain from this example (and may not have this issue with 2099 rollover), 
so maybe this year code should be in the library?

I will remove 2099+ support if you continue to consider this rollover 
issue egregious given my rationalization.

Sincerely -- Mark Salyzyn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/