On Wed, Dec 02, 2020 at 11:08:38PM +0100, Thomas Gleixner wrote: > > > > arch/x86/kernel/kvmclock.c: x86_platform.set_wallclock = > > kvm_set_wallclock; > > arch/x86/kernel/x86_init.c: x86_platform.set_wallclock = > > set_rtc_noop; > > arch/x86/xen/time.c: x86_platform.set_wallclock = > > xen_set_wallclock; > > arch/x86/xen/time.c: x86_platform.set_wallclock = xen_set_wallclock; > > All returns -ENODEV/EINVAL > > You forgot to stare at the .get_wallclock() functions. That's the more > interesting part, i.e. what's behind read_persistent_clock64().
Small steps! I was only looking at deleting the legacy CONFIG_GENERIC_CMOS_UPDATE from x86 which only controls the update_persistent_clock64() Yes, there is a similar redundancy with rtclib on the read_persistant_clock side, and that does looks much further.. > > arch/x86/kernel/x86_init.c: .set_wallclock = > > mach_set_rtc_mmss, > > This is already rtclib under drivers/rtc/rtc-mc146818-lib.c > > That's the shared library function for setting the darn thing. Yes, but if a PNP entry is present then rtc-cmos will load and call that function through the rtclib path instead of the update_persistent_clock64() path Jason
