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: <20230517121925.518473aa@kernel.org>
Date: Wed, 17 May 2023 12:19:25 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: "Russell King (Oracle)" <linux@...linux.org.uk>, Andrew Lunn
 <andrew@...n.ch>, Köry Maincent
 <kory.maincent@...tlin.com>, netdev@...r.kernel.org, glipus@...il.com,
 maxime.chevallier@...tlin.com, vadim.fedorenko@...ux.dev,
 richardcochran@...il.com, gerhard@...leder-embedded.com,
 thomas.petazzoni@...tlin.com, krzysztof.kozlowski+dt@...aro.org,
 robh+dt@...nel.org
Subject: Re: [PATCH net-next RFC v4 2/5] net: Expose available time stamping
 layers to user space.

On Fri, 12 May 2023 10:38:52 -0700 Jakub Kicinski wrote:
> On Fri, 12 May 2023 13:29:11 +0300 Vladimir Oltean wrote:
> > On Thu, May 11, 2023 at 04:16:25PM -0700, Jakub Kicinski wrote:  
> > > Oh, you should tell me, maybe off-list then. 'Cause I don't know any.    
> > 
> > I hope the examples given in private will make you reconsider the
> > validity of my argument about DMA timestamps.  
> 
> I may have lost track of what the argument is. There are devices
> which will provide a DMA stamp for Tx and Rx. We need an API that'll
> inform the user about it. 
> 
> To be clear I'm talking about drivers which are already in the tree,
> not opening the door for some shoddy new HW in.

It dawned on me while reading a phylink discussion that I may have
misunderstood the meaning of the MAC vs PHY time stamp sources.
By the standard - stamping happens under the MAC, so MAC is 
the "right" place to stamp, not the PHY. And there can be multiple 
PHYs technically? Are we just using the MAC vs PHY thing as an
implementation aid, to know which driver to send the request to?

Shouldn't we use the clock ID instead?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ