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: <20250409171055.43e51012@fedora.home>
Date: Wed, 9 Apr 2025 17:10:55 +0200
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: Kory Maincent <kory.maincent@...tlin.com>
Cc: "Russell King (Oracle)" <linux@...linux.org.uk>, Andrew Lunn
 <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
 <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Marek BehĂșn <kabel@...nel.org>, Richard Cochran
 <richardcochran@...il.com>, Thomas Petazzoni
 <thomas.petazzoni@...tlin.com>, linux-kernel@...r.kernel.org,
 netdev@...r.kernel.org, Vladimir Oltean <vladimir.oltean@....com>
Subject: Re: [PATCH net-next v2 0/2] Add Marvell PHY PTP support

On Wed, 9 Apr 2025 16:49:20 +0200
Kory Maincent <kory.maincent@...tlin.com> wrote:

> On Wed, 9 Apr 2025 14:46:54 +0200
> Maxime Chevallier <maxime.chevallier@...tlin.com> wrote:
> 
> > On Wed, 9 Apr 2025 14:23:09 +0200
> > Kory Maincent <kory.maincent@...tlin.com> wrote:
> >   
> > > On Wed, 9 Apr 2025 10:29:52 +0100
> > > "Russell King (Oracle)" <linux@...linux.org.uk> wrote:
> > >     
> > > > On Wed, Apr 09, 2025 at 10:46:37AM +0200, Kory Maincent wrote:      
> >  [...]    
> > >     
> >  [...]  
> >  [...]    
> > > > 
> > > > How do I know that from the output? Nothing in the output appears to
> > > > tells me which PTP implementation will be used.
> > > > 
> > > > Maybe you have some understanding that makes this obvious that I don't
> > > > have.      
> > > 
> > > You are right there is no report of the PTP source device info in ethtool.
> > > With all the design change of the PTP series this has not made through my
> > > brain that we lost this information along the way.
> > > 
> > > You can still know the source like that but that's not the best.
> > > # ls -l /sys/class/ptp
> > > 
> > > It will be easy to add the source name support in netlink but which names
> > > are better report to the user?
> > > - dev_name of the netdev->dev and phydev->mdio.dev?
> > >   Maybe not the best naming for the phy PTP source
> > >   (ff0d0000.ethernet-ffffffff:01)
> > > - "PHY" + the PHY ID and "MAC" string?    
> > 
> > How about an enum instead of a string indicating the device type, and if
> > PHY, the phy_index ? (phy ID has another meaning :) )  
> 
> This will raise the same question I faced during the ptp series mainline
> process. In Linux, the PTP is managed through netdev or phylib API.
> In case of a NIC all is managed through netdev. So if a NIC has a PTP at the PHY
> layer how should we report that? As MAC PTP because it goes thought netdev, as
> PHY PTP but without phyindex?

Are you referring to the case where the PHY is transparently handled by
the MAC driver (i.e. controlled through a firmware of some sort) ?

In such case, how do you even know that timestamping is done in a PHY,
as the kernel doesn't know the PHY even exists ? The
HWTSTAMP_SOURCE_XXX enum either says it's from PHYLIB or NETDEV. As
PHYs handled by firmwares don't go through phylib, I'd say reporting
"PHY with no index" won't be accurate.

In such case I'd probably expect the NIC driver to register several
hwtstamp_provider with different qualifiers

> That's why maybe using netlink string could assure we won't have UAPI breakage
> in the future due to weird cases.
> What do you think?

Well I'd say this is the same for enums, nothing prevents you from
adding more values to your enum ?

Maxime

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ