[PATCH] rtc: Allow rtc drivers to specify the tv_nsec value for ntp

[linux@armlinux.org.uk (Russell King - ARM Linux)]

On Mon, Nov 27, 2017 at 09:35:30AM -0800, John Stultz wrote:
> On Thu, Nov 23, 2017 at 1:54 AM, Alexandre Belloni
> <alexandre.belloni@free-electrons.com> wrote:
> > Hi,
> >
> > On 13/10/2017 at 11:54:33 -0600, Jason Gunthorpe wrote:
> >> ntp is currently hardwired to try and call the rtc set when wall clock
> >> tv_nsec is 0.5 seconds. This historical behaviour works well with certain
> >> PC RTCs, but is not universal to all rtc hardware.
> >>
> >> Change how this works by introducing the driver specific concept of
> >> set_offset_nsec, the delay between current wall clock time and the target
> >> time to set (with a 0 tv_nsecs).
> >>
> >> For x86-style CMOS set_offset_nsec should be -0.5 s which causes the last
> >> second to be written 0.5 s after it has started.
> >>
> >> For compat with the old rtc_set_ntp_time, the value is defaulted to
> >> + 0.5 s, which causes the next second to be written 0.5s before it starts,
> >> as things were before this patch.
> >>
> >> Testing shows many non-x86 RTCs would like set_offset_nsec ~= 0,
> >> so ultimately each RTC driver should set the set_offset_nsec according
> >> to its needs, and non x86 architectures should stop using
> >> update_persistent_clock64 in order to access this feature.
> >> Future patches will revise the drivers as needed.
> >>
> >> Since CMOS and RTC now have very different handling they are split
> >> into two dedicated code paths, sharing the support code, and ifdefs
> >> are replaced with IS_ENABLED.
> >>
> >> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
> >> ---
> >>  drivers/rtc/class.c   |   3 +
> >>  drivers/rtc/systohc.c |  53 +++++++++++-----
> >>  include/linux/rtc.h   |  43 ++++++++++++-
> >>  kernel/time/ntp.c     | 166 ++++++++++++++++++++++++++++++++++----------------
> >>  4 files changed, 196 insertions(+), 69 deletions(-)
> >>
> >> Hello All,
> >>
> >> Here is the latest version of this patch that was circulating between
> >> RMK and myself. I have done a few more minor changed and been able to
> >> test it myself on x86 KVM and on the ARM system that motivated the
> >> original CONFIG_RTC_SYSTOHC patch.
> >>
> >> From all my testing, this patch does not change the existing behavior
> >> at all, but provides the base infrastructure to fix individual RTCs
> >> one at a time.
> >>
> >> There are a few followup patches that will set the set_offset_nsec
> >> value for various RTC drivers, and I still have to look at RMK's
> >> hrtimer patch, but those are all incremental on top of this.
> >>
> >
> > So I'm discovering that this patch made it upstream silently. While it
> > somewhat solves the issue for some RTCs, it is not a proper solution for
> > most.
> 
> Sorry. I thought the discussion had finished up and it looked ok, so I
> queued it up. Apologies.

I'm actually rather disappointed that Alexandre Belloni has only now
brought up his dis-satisfaction with the approach after all the effort
that Jason and myself have put in to it.  It's not like Alexandre was
not copied on the patches and discussion.

If Alexandre could not be bothered to bring up his concerns while the
discussion was on-going in September, and didn't bother raising them
in October, I'd say that Alexandre's opinion at this point doesn't
count for much - if it wasn't important to state at the time or for
a couple of months after, why does it become important to state after
the thing has been merged.

Maybe the idea here is basically to waste people's time letting them
develop a patch for an approach, and then object at the last minute
to that approach.  Hardly seems fair or even reasonable.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up