Re: [PATCH net-next v2 0/2] Add Marvell PHY PTP support

[Kory Maincent]

On Wed, 9 Apr 2025 14:46:54 +0200
Maxime Chevallier <maxime.chevallier@xxxxxxxxxxx> wrote:

> On Wed, 9 Apr 2025 14:23:09 +0200
> Kory Maincent <kory.maincent@xxxxxxxxxxx> wrote:
> 
> > On Wed, 9 Apr 2025 10:29:52 +0100
> > "Russell King (Oracle)" <linux@xxxxxxxxxxxxxxx> 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?
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?
 
Regards,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com