[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210113190555.095bf937@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date: Wed, 13 Jan 2021 19:05:55 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Andrew Lunn <andrew@...n.ch>,
Russell King <rmk+kernel@...linux.org.uk>
Cc: Richard Cochran <richardcochran@...il.com>,
Heiner Kallweit <hkallweit1@...il.com>,
"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] net: ethtool: allow MAC drivers to override
ethtool get_ts_info
On Sun, 10 Jan 2021 17:35:25 +0100 Andrew Lunn wrote:
> On Sun, Jan 10, 2021 at 11:13:44AM +0000, Russell King wrote:
> > Check whether the MAC driver has implemented the get_ts_info()
> > method first, and call it if present. If this method returns
> > -EOPNOTSUPP, defer to the phylib or default implementation.
> >
> > This allows network drivers such as mvpp2 to use their more accurate
> > timestamping implementation than using a less accurate implementation
> > in the PHY. Network drivers can opt to defer to phylib by returning
> > -EOPNOTSUPP.
> >
> > This change will be needed if the Marvell PHY drivers add support for
> > PTP.
> >
> > Note: this may cause a change for any drivers that use phylib and
> > provide get_ts_info(). It is not obvious if any such cases exist.
>
> Hi Russell
>
> We can detect that condition through? Call both, then do a WARN() if
> we are changing the order? Maybe we should do that for a couple of
> cycles?
>
> For netlink ethtool, we can also provide an additional attribute. A
> MAC, or PHY indicator we can do in the core. A string for the name of
> the driver would need a bigger change.
I'm not seeing a response to this suggestion, did vger eat it?
Powered by blists - more mailing lists