netdev - Re: [PATCH net-next v5 08/16] net: ethtool: Add a command to expose current time stamping layer

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: <20231017112122.1548bb57@kmaincent-XPS-13-7390>
Date: Tue, 17 Oct 2023 11:21:22 +0200
From: Köry Maincent <kory.maincent@...tlin.com>
To: Jacob Keller <jacob.e.keller@...el.com>
Cc: Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>, Florian
 Fainelli <florian.fainelli@...adcom.com>, <netdev@...r.kernel.org>,
 <linux-kernel@...r.kernel.org>, <linux-doc@...r.kernel.org>, Thomas
 Petazzoni <thomas.petazzoni@...tlin.com>, "David S . Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
 <pabeni@...hat.com>, "Jonathan Corbet" <corbet@....net>, Jay Vosburgh
 <j.vosburgh@...il.com>, Andy Gospodarek <andy@...yhouse.net>, Nicolas Ferre
 <nicolas.ferre@...rochip.com>, "Claudiu Beznea" <claudiu.beznea@...on.dev>,
 Horatiu Vultur <horatiu.vultur@...rochip.com>,
 <UNGLinuxDriver@...rochip.com>, "Broadcom internal kernel review list"
 <bcm-kernel-feedback-list@...adcom.com>, "Heiner Kallweit"
 <hkallweit1@...il.com>, Russell King <linux@...linux.org.uk>, Richard
 Cochran <richardcochran@...il.com>, Radu Pirea
 <radu-nicolae.pirea@....nxp.com>, Willem de Bruijn
 <willemdebruijn.kernel@...il.com>, Vladimir Oltean
 <vladimir.oltean@....com>, Michael Walle <michael@...le.cc>, Maxime
 Chevallier <maxime.chevallier@...tlin.com>
Subject: Re: [PATCH net-next v5 08/16] net: ethtool: Add a command to expose
 current time stamping layer

On Mon, 16 Oct 2023 16:03:13 -0700
Jacob Keller <jacob.e.keller@...el.com> wrote:

> On 10/16/2023 10:03 AM, Jakub Kicinski wrote:
> > On Mon, 16 Oct 2023 18:23:07 +0200 Köry Maincent wrote:  
> >>> What's the reason for timestamp precision differences?
> >>> My understanding so far was the the differences come from:
> >>>  1. different stamping device (i.e. separate "piece of silicon",
> >>>     accessed over a different bus, with different PHC etc.)
> >>>  2. different stamping point (MAC vs DMA)
> >>>
> >>> I don't think any "integrated" device would support stamps which
> >>> differ under category 1.    
> >>
> >> It was a case reported by Maxime on v3:
> >> https://lore.kernel.org/netdev/20230324112541.0b3dd38a@pc-7.home/   
> > 
> > IMHO this talks about how clock control/disciplining works which
> > is a somewhat independent topic of timestamping.  
> 
> The thread in question mentions that the device has two modes, one which
> has higher precision for the timestamps, and one which has better
> precision on frequency adjustments. I don't know the details for why the
> hardware has this behavior, but being able to switch between the two
> timestamp modes has value as described by the thread.
> 
> I'm not sure how to represent that in such an API because both modes
> seem to capture the timestamp at the MAC.

After some thought, indeed moving back to MAC/PHY_TIMESTAMPING seems better.
This case of several timestamp modes in MAC is currently only for the special
stmmac case.
We could support it the same way we could support multiPHY by saving the
source id of the timestamp like this in net_device:
struct {
	enum ts_layer layer,
	int source_id,
} ts