Re: [RFC PATCH 0/1] timekeeping: Don't charge NTP frequency changes to ntp_error

[David Woodhouse]

On Wed, 2026-11-04 at 20:29 -0800, Woodhouse, David wrote:
> On Thu, 2026-11-05 at 11:21 +0800, Yuan Wang wrote:
> > 
> > Open question, mainly for David: if timekeeping_set_reference() (ffclock
> > branch) changes tick_length, it would now also be applied "at the time of
> > the update". If that path needs the as-if-at-tick semantics, I'd suggest
> > it delivers the phase through time_offset (which the series now makes
> > exact) or passes an explicit flag down to timekeeping_adjust(); happy to
> > rework the patch either way.
> 
> Yeah, timekeeping_set_reference() doesn't care. It's going to reset
> ntp_error *after* changing the tick_length anyway.
> 
> I think your patch is functionally identical to the one I've already
> posted in 
> https://lore.kernel.org/all/20261001202134.33929-2-dwmw2@xxxxxxxxxxxxx/ ;?

Not *quite* functionally identical; I think your version misses the
ntp_error updates that we *should* be doing, when tick_length changes
while a skew is active? Mine compensates only for the tick_length part,
which I think is correct?

I'm due to send v2 of that series; please could you test that, and I'll
add the appropriate Fixes: and Cc: stable with your Tested-by:.

Thanks.

Attachment: smime.p7s
Description: S/MIME cryptographic signature