Re: [PATCH v3 4/5] rtc: mt6397: Remove start time parameters

[Alexandre Belloni <alexandre.belloni@bootlin.com>]

On 14/04/2025 23:34:48+0200, Uwe Kleine-König wrote:
> > > Yes, you're stuck with this. Devicetree has to be retrocompatible.
> > > 
> > > Besides, this start_secs is what gets used by default, and the start-year
> > > devicetree property should take precedence and effectively override the
> > > start_secs default.
> > > 
> > > Just keep it there.... :-)
> 
> It would work to keep setting start_secs but allow overwriting that
> value in the device tree. But see below.
>  

This is already the case.

> > When you boot your board for the first time, is the date January 2nd 1968 ?
> > If not, that mean it is used as a finetune offset year.
> > IMHO, mktime64(1968, 1, 2, 0, 0, 0) is a workaround for the rtc framework
> > issue we try to solve in this serie because start_secs is negative (1968 <
> > 1970). Now framework handle the negative value properly, even if you keep
> > mktime64(1968, 1, 2, 0, 0, 0) , the device time will change. I prefer to
> > notify you.  :)
> 
> I don't understand everything you wrote here, but as far as I see it,
> rtc_time64_to_tm() not being able to handle dates before 1970 is the
> main issue here. This is of course only relevant, because your hardware
> occasionally contains such a date. The technically right fix is to
> extend rtc_time64_to_tm() to work for dates >= 1900-01-01. (An
> alternative would be to assume that a hardware read returning a date
> before 1970 is invalid. If you refuse to write dates before 1970 that
> should give a consistent behaviour. But the original approach is the
> nicer one.)
> 

Yes, the assumption is that dates before 1970 are definitively invalid.
I still believe we live in a world were the time doesn't go back ;)

Android *was* the only OS requiring to be able to set 01/01/1970. This
changed after they realized that some hardware is not able to do that.

> > TBH, it's hard to follow the logic, so I've a question:
> > If I push in my V4 a framework fix that drivers using year < 1970 will need
> > to have a new start_secs or start-year value to stay aligned with there
> > previous value, do you will accept it ?
> 
> Doesn't the need to shift the start year simply goes away once
> rtc_time64_to_tm() is fixed for negative time values?
> 
> So I would expect that going forward with just patches #1 and #2 should
> result in a fixed driver regarding the breakage you're seeing. (I'm
> unsure about patch #3, I'll address that in a reply to the respective
> mail.)
> 

This is also what I think but I don't think I'm going to allow the
rtc_valid_tm() change. It shouldn't matter as the check should always
happen after offsetting/windowing.

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com