diff options
author | Peter Hilber <peter.hilber@opensynergy.com> | 2023-12-18 08:38:41 +0100 |
---|---|---|
committer | Thomas Gleixner <tglx@linutronix.de> | 2024-02-19 12:18:51 +0100 |
commit | 14274d0bd31b4debf28284604589f596ad2e99f2 (patch) | |
tree | ce0b08586b6864c3e6508eef86d7b6b6ae0d0af0 /drivers/net/team/team_mode_random.c | |
parent | 87a41130881995f82f7adbafbfeddaebfb35f0ef (diff) | |
download | linux-14274d0bd31b4debf28284604589f596ad2e99f2.tar.gz linux-14274d0bd31b4debf28284604589f596ad2e99f2.tar.bz2 linux-14274d0bd31b4debf28284604589f596ad2e99f2.zip |
timekeeping: Fix cross-timestamp interpolation for non-x86
So far, get_device_system_crosststamp() unconditionally passes
system_counterval.cycles to timekeeping_cycles_to_ns(). But when
interpolating system time (do_interp == true), system_counterval.cycles is
before tkr_mono.cycle_last, contrary to the timekeeping_cycles_to_ns()
expectations.
On x86, CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE will mitigate on
interpolating, setting delta to 0. With delta == 0, xtstamp->sys_monoraw
and xtstamp->sys_realtime are then set to the last update time, as
implicitly expected by adjust_historical_crosststamp(). On other
architectures, the resulting nonsense xtstamp->sys_monoraw and
xtstamp->sys_realtime corrupt the xtstamp (ts) adjustment in
adjust_historical_crosststamp().
Fix this by deriving xtstamp->sys_monoraw and xtstamp->sys_realtime from
the last update time when interpolating, by using the local variable
"cycles". The local variable already has the right value when
interpolating, unlike system_counterval.cycles.
Fixes: 2c756feb18d9 ("time: Add history to cross timestamp interface supporting slower devices")
Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: John Stultz <jstultz@google.com>
Link: https://lore.kernel.org/r/20231218073849.35294-4-peter.hilber@opensynergy.com
Diffstat (limited to 'drivers/net/team/team_mode_random.c')
0 files changed, 0 insertions, 0 deletions