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

[Kory Maincent <kory.maincent@bootlin.com>]

On Wed, 9 Apr 2025 17:10:55 +0200
Maxime Chevallier <maxime.chevallier@bootlin.com> wrote:

> On Wed, 9 Apr 2025 16:49:20 +0200
> Kory Maincent <kory.maincent@bootlin.com> wrote:
> 
> > On Wed, 9 Apr 2025 14:46:54 +0200
> > Maxime Chevallier <maxime.chevallier@bootlin.com> wrote:
> >   
> > > On Wed, 9 Apr 2025 14:23:09 +0200
> > > Kory Maincent <kory.maincent@bootlin.com> wrote:

> > > 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) ?

Yes I was.
 
> 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 ?

Thanks! I am ok with that.

Regards,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com