17:30 <marex> abelloni: hi, I ran across CONFIG_RTC_HCTOSYS_DEVICE, but that looks odd ; the probe order of various RTCs is not stable on boot, so whatever is rtc0 , rtc1 , etc. might change every boot -- so how do I specify the preferred RTC from which the kernel should pull current time really ?

17:30 <abelloni> you don't

17:31 <abelloni> you should avoid using RTC_HCTOSYS

17:31 <marex> abelloni: oh ?

17:31 <marex> abelloni: so what does set the system time (from rtc) early on then ?

17:31 <abelloni> userspace ?

17:32 <abelloni> why do you want the kernel to set the time in the frst place ?

17:32 <marex> abelloni: well, I just spent the last few hours digging through systemd sources , only to find out it is unable to set system time from RTC if it has no network connection (no NTP access)

17:33 <marex> abelloni: so it merrily sets system time to its build time and ... done

17:33 <abelloni> else, the answer to your original question is to use DT aliases

17:33 <abelloni> marex: yes, there is a bug opened for systemd

17:33 <abelloni> where lennart and I disagree

17:33 <marex> :-)

17:35 <marex> abelloni: got a link ?

17:35 <abelloni> he says the kernel has to do it, I say userspace is better equipped

17:36 <marex> abelloni: heh

17:37 <marex> abelloni: I think its a different point of view, Lennart sees it from the server-end, where there is one RTC which just works ; you see it from embedded system view where there are three RTCs and each broken in different way

17:38 <abelloni> https://github.com/systemd/systemd/issues/1143

17:38 <abelloni> https://github.com/systemd/systemd/issues/17737

17:38 <abelloni> one of those

17:39 <abelloni> marex: exactly

17:39 <abelloni> marex: but really, just use aliases

17:39 <marex> abelloni: I totally did miss the alias support, and that seems what I need, thanks for that

18:17 <geertu> abelloni: I use CONFIG_RTC_HCTOSYS_DEVICE="rtc0" on m68k because else it runs e2fsck on every boot

19:18 <ukleinek> geertu: it shouldn't. AFAIK systemd sets the date to max(build-date, last-shutdown, most-recently-saved-runtime-timestamp)

19:19 <Xogium> ukleinek is right, but it could happen if fsck is executed before timesync is ran

19:19 <Xogium> afaik

19:20 <Xogium> I believe it is timesync that advances the clock

19:21 <Xogium> though… Maybe not ?

19:22 <Xogium> I know for a fact timesyncd is the one that restore time from disk, unless this changed

19:22 <Xogium> but maybe advancing the clock to the latest build date of systemd is done by pid 1

19:23 <Xogium> that being said, if it is running fsck before the time from disk is restored, I can see why it would have a bit of a problem

19:23 <Xogium> if you go for example 4 months into the past at each reboot

19:43 <abelloni> even then, I guess the time could be read from the RTC and set to the system time before running fsck

19:43 <abelloni> because at that point you have a userspace right ?

21:30 <marex> robher: hi, so, I ran across another oddity while fixing up dtbs_check warnings

21:31 <marex> arch/arm/boot/dts/stm32mp157a-dhcor-avenger96.dt.yaml: led: led1:default-state:0: 'off' is not of type 'array'

21:31 <marex> arch/arm/boot/dts/stm32mp153c-dhcom-drc02.dt.yaml:0:0: /reserved-memory/mcuram2@10000000: failed to match any schema with compatible: ['shared-dma-pool']

21:31 <marex> these two

21:31 <marex> it seems like they are both schema-side issues, or ?