linux-kernel - Re: [PATCH net-next 2/3] net: stmmac: Allow supporting coarse adjustment mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251017182358.42f76387@kernel.org>
Date: Fri, 17 Oct 2025 18:23:58 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>
Cc: Alexandre Torgue <alexandre.torgue@...s.st.com>, Jose Abreu
 <joabreu@...opsys.com>, Andrew Lunn <andrew+netdev@...n.ch>,
 davem@...emloft.net, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
 <pabeni@...hat.com>, Maxime Coquelin <mcoquelin.stm32@...il.com>, Richard
 Cochran <richardcochran@...il.com>, Russell King <linux@...linux.org.uk>,
 Köry Maincent <kory.maincent@...tlin.com>, Alexis
 Lothoré <alexis.lothore@...tlin.com>, Thomas Petazzoni
 <thomas.petazzoni@...tlin.com>, netdev@...r.kernel.org,
 linux-stm32@...md-mailman.stormreply.com,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 2/3] net: stmmac: Allow supporting coarse
 adjustment mode

On Wed, 15 Oct 2025 12:27:22 +0200 Maxime Chevallier wrote:
> The DWMAC1000 supports 2 timestamping configurations to configure how
> frequency adjustments are made to the ptp_clock, as well as the reported
> timestamp values.
> 
> There was a previous attempt at upstreaming support for configuring this
> mode by Olivier Dautricourt and Julien Beraud a few years back [1]
> 
> In a nutshell, the timestamping can be either set in fine mode or in
> coarse mode.
> 
> In fine mode, which is the default, we use the overflow of an accumulator to
> trigger frequency adjustments, but by doing so we lose precision on the
> timetamps that are produced by the timestamping unit. The main drawback
> is that the sub-second increment value, used to generate timestamps, can't be
> set to lower than (2 / ptp_clock_freq).
> 
> The "fine" qualification comes from the frequent frequency adjustments we are
> able to do, which is perfect for a PTP follower usecase.
> 
> In Coarse mode, we don't do frequency adjustments based on an
> accumulator overflow. We can therefore have very fine subsecond
> increment values, allowing for better timestamping precision. However
> this mode works best when the ptp clock frequency is adjusted based on
> an external signal, such as a PPS input produced by a GPS clock. This
> mode is therefore perfect for a Grand-master usecase.
> 
> We therefore attempt to map these 2 modes with the newly introduced
> hwtimestamp qualifiers (precise and approx).
> 
> Precise mode is mapped to stmmac fine mode, and is the expected default,
> suitable for all cases and perfect for follower mode
> 
> Approx mode is mapped to coarse mode, suitable for Grand-master.

I failed to understand what this device does and what the problem is :(

What is your ptp_clock_freq? Isn't it around 50MHz typically? 
So 2 / ptp_freq is 40nsec (?), not too bad?

My recollection of the idea behind that timestamping providers
was that you can configure different filters for different providers.
IOW that you'd be able to say:
 - [precise] Rx stamp PTP packets 
 -  [approx] Rx stamp all packets
not that you'd configure precision of one piece of HW..

If the HW really needs it, just lob a devlink param at it?