[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260119115710.6fdde8c0@kernel.org>
Date: Mon, 19 Jan 2026 11:57:10 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Willem de Bruijn <willemb@...gle.com>
Cc: Kevin Yang <yyd@...gle.com>, Harshitha Ramamurthy
<hramamurthy@...gle.com>, Andrew Lunn <andrew+netdev@...n.ch>, David Miller
<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
<pabeni@...hat.com>, Joshua Washington <joshwash@...gle.com>, Gerhard
Engleder <gerhard@...leder-embedded.com>, Richard Cochran
<richardcochran@...il.com>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 1/2] net: extend ndo_get_tstamp for other
timestamp types
On Thu, 15 Jan 2026 22:22:59 +0000 Kevin Yang wrote:
> Reviewed-by: Willem de Bruijn <willemb@...gle.com>
Other than expediency why implementing this in drivers makes sense?
There will be very little driver specific logic here.
After thinking about it for 1 minute my intuition would be for drivers
to just expose necessary information, in-kernel consumers should
"enable" the sync for all netdevs during init, and then convert
the timestamps into REALTIME / MONOTONIC by calling some helper?
Also AI code review says:
> + mult = mult_frac(GVE_HWTS_REAL_CC_NOMINAL,
> + real_ns - priv->ts_real.last_sync_ns,
> + priv->last_sync_nic_counter - prev_nic);
Can this divide by zero?
--
pw-bot: cr
Powered by blists - more mailing lists