Messages in this thread | | | Date | Wed, 2 Dec 2020 19:03:03 -0400 | From | Jason Gunthorpe <> | Subject | Re: [PATCH] rtc: adapt allowed RTC update error |
| |
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
| |