[SRU][F/raspi][PATCH] rtc: class: support hctosys from modular RTC drivers

[Dimitri John Ledkov]

On Tue, May 4, 2021 at 6:39 PM Krzysztof Kozlowski
<krzysztof.kozlowski at canonical.com> wrote:
>
> On 04/05/2021 13:22, Dimitri John Ledkov wrote:
> > Hi,
> >
> > This will introduce a regression in certain configurations as
> > mentioned on https://github.com/systemd/systemd/issues/17737
> >
> > I had a tentative patch to kernel to only advance time in rtc_hctosys
> > only if it is newer than the one returned by ktime_get_real_ts64.
>
> That's the mainline commit, so change for it (e.g. do not set the system
> clock for modules) should go via upstream.
>
> > However that went nowhere.
> >
> > If this is cherry picked, imho we must change config
> > CONFIG_RTC_HCTOSYS or at least set it to something sane because
> > currently on raspi it is set to CONFIG_RTC_HCTOSYS_DEVICE="rtc0" which
> > always points at the non-battery backed RTC from the SOC.
>
> RPi does not have a RTC, so whoever adds it via overlay, probably
> chooses one with a battery. Otherwise there is no much point of having
> RTC...

That. I just don't know which RTC are available as rpi-hats and which
dtb overlay they use and which rtc name they end up with.

If the properly working & battery backed RTC is added via overlay dtb
and it ends up having rtc0 name, everything is fine. I just don't know
if the overlays remove all other rtc nodes and like take over the rtc0
name.

@juerg do rpi RTCs with batteries end up having rtc0 kernel name? or
do they end up with something else? Also we must include them into the
initrd as modules for UC20 cause otherwise it would be odd if the
clock jumps after pivot to root & after NTP got network time.

-- 
Regards,

Dimitri.