[v3,3/5] net: Let the active time stamping layer be selectable.

  From: Richard Cochran <richardcochran@gmail.com>

Add the ETHTOOL_SET_PTP ethtool ioctl, and add checks in the ioctl and time
stamping paths to respect the currently selected time stamping layer.

Add a preferred-timestamp devicetree binding to select the preferred
hardware timestamp layer between PHY and MAC. The choice of using
devicetree binding has been made as the PTP precision and quality depends
of external things, like adjustable clock, or the lack of a temperature
compensated crystal or specific features. Even if the preferred timestamp
is a configuration it is hardly related to the design oh the board.

Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
---

Notes:
    Changes in v2:
    - Move selected_timestamping_layer introduction in this patch.
    - Replace strmcmp by sysfs_streq.
    - Use the PHY timestamp only if available.
    
    Changes in v3:
    - Added a devicetree binding to select the preferred timestamp
    - Replace the way to select timestamp through ethtool instead of sysfs
    You can test it with the ethtool source on branch feature_ptp of:
    https://github.com/kmaincent/ethtool

 Documentation/networking/ethtool-netlink.rst |  1 +
 drivers/net/phy/phy_device.c                 | 34 ++++++++++++++++
 include/linux/netdevice.h                    |  6 +++
 include/uapi/linux/ethtool.h                 |  1 +
 net/core/dev_ioctl.c                         | 43 ++++++++++++++++++--
 net/core/timestamping.c                      |  6 +++
 net/ethtool/common.c                         | 16 ++++++--
 net/ethtool/ioctl.c                          | 41 ++++++++++++++-----
 8 files changed, 131 insertions(+), 17 deletions(-)
  

Köry Maincent wrote:
> From: Richard Cochran <richardcochran@gmail.com>
> 
> Add the ETHTOOL_SET_PTP ethtool ioctl, and add checks in the ioctl and time
> stamping paths to respect the currently selected time stamping layer.
> 
> Add a preferred-timestamp devicetree binding to select the preferred
> hardware timestamp layer between PHY and MAC. The choice of using
> devicetree binding has been made as the PTP precision and quality depends
> of external things, like adjustable clock, or the lack of a temperature
> compensated crystal or specific features. Even if the preferred timestamp
> is a configuration it is hardly related to the design oh the board.

nit: oh -> of

> 
> Signed-off-by: Richard Cochran <richardcochran@gmail.com>
> Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
> ---
> 
> Notes:
>     Changes in v2:
>     - Move selected_timestamping_layer introduction in this patch.
>     - Replace strmcmp by sysfs_streq.
>     - Use the PHY timestamp only if available.
>     
>     Changes in v3:
>     - Added a devicetree binding to select the preferred timestamp
>     - Replace the way to select timestamp through ethtool instead of sysfs
>     You can test it with the ethtool source on branch feature_ptp of:
>     https://github.com/kmaincent/ethtool
> 
>  Documentation/networking/ethtool-netlink.rst |  1 +
>  drivers/net/phy/phy_device.c                 | 34 ++++++++++++++++
>  include/linux/netdevice.h                    |  6 +++
>  include/uapi/linux/ethtool.h                 |  1 +
>  net/core/dev_ioctl.c                         | 43 ++++++++++++++++++--
>  net/core/timestamping.c                      |  6 +++
>  net/ethtool/common.c                         | 16 ++++++--
>  net/ethtool/ioctl.c                          | 41 ++++++++++++++-----
>  8 files changed, 131 insertions(+), 17 deletions(-)
> 
> +void of_set_timestamp(struct net_device *netdev, struct phy_device *phydev)
> +{
> +	struct device_node *node = phydev->mdio.dev.of_node;
> +	const struct ethtool_ops *ops = netdev->ethtool_ops;
> +	const char *s;
> +	enum timestamping_layer ts_layer = 0;
> +
> +	if (phy_has_hwtstamp(phydev))
> +		ts_layer = PHY_TIMESTAMPING;
> +	else if (ops->get_ts_info)
> +		ts_layer = MAC_TIMESTAMPING;
> +
> +	if (of_property_read_string(node, "preferred-timestamp", &s))
> +		goto out;
> +
> +	if (!s)
> +		goto out;
> +
> +	if (phy_has_hwtstamp(phydev) && !strcmp(s, "phy"))
> +		ts_layer = PHY_TIMESTAMPING;
> +
> +	if (ops->get_ts_info && !strcmp(s, "mac"))
> +		ts_layer = MAC_TIMESTAMPING;
> +
> +out:
> +	netdev->selected_timestamping_layer = ts_layer;
> +}
> +
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index ba2bd604359d..d9a1c12fc43c 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -47,6 +47,7 @@
>  #include <uapi/linux/netdevice.h>
>  #include <uapi/linux/if_bonding.h>
>  #include <uapi/linux/pkt_cls.h>
> +#include <uapi/linux/net_tstamp.h>
>  #include <linux/hashtable.h>
>  #include <linux/rbtree.h>
>  #include <net/net_trackers.h>
> @@ -1981,6 +1982,9 @@ enum netdev_ml_priv_type {
>   *
>   *	@threaded:	napi threaded mode is enabled
>   *
> + *	@selected_timestamping_layer:	Tracks whether the MAC or the PHY
> + *					performs packet time stamping.
> + *
>   *	@net_notifier_list:	List of per-net netdev notifier block
>   *				that follow this device when it is moved
>   *				to another network namespace.
> @@ -2339,6 +2343,8 @@ struct net_device {
>  	unsigned		wol_enabled:1;
>  	unsigned		threaded:1;
>  
> +	enum timestamping_layer selected_timestamping_layer;
> +

can perhaps be a single bit rather than an enum

> +static int dev_hwtstamp_ioctl(struct net_device *dev,
> +			      struct ifreq *ifr, unsigned int cmd)
> +{
> +	const struct net_device_ops *ops = dev->netdev_ops;
> +	int err;
> +
> +	err = dsa_ndo_eth_ioctl(dev, ifr, cmd);
> +	if (err == 0 || err != -EOPNOTSUPP)
> +		return err;
> +
> +	if (!netif_device_present(dev))
> +		return -ENODEV;
> +
> +	switch (dev->selected_timestamping_layer) {
> +	case MAC_TIMESTAMPING:
> +		if (ops->ndo_do_ioctl == phy_do_ioctl) {
> +			/* Some drivers set .ndo_do_ioctl to phy_do_ioctl. */
> +			err = -EOPNOTSUPP;
> +		} else {
> +			err = ops->ndo_eth_ioctl(dev, ifr, cmd);
> +		}
> +		break;
> +
> +	case PHY_TIMESTAMPING:
> +		if (phy_has_hwtstamp(dev->phydev)) {
> +			err = phy_mii_ioctl(dev->phydev, ifr, cmd);
> +		} else {
> +			err = -ENODEV;
> +			WARN_ON(1);

Please no WARN_ON on error cases that are known to be reachable
and can be handled safely and reported to userspace.

> +		}
> +		break;
> +	}
> +
> +	return err;
> +}
> +
> diff --git a/net/ethtool/common.c b/net/ethtool/common.c
> index 64a7e05cf2c2..e55e70bdbb3c 100644
> --- a/net/ethtool/common.c
> +++ b/net/ethtool/common.c
> @@ -548,10 +548,18 @@ int __ethtool_get_ts_info(struct net_device *dev, struct ethtool_ts_info *info)
>  	memset(info, 0, sizeof(*info));
>  	info->cmd = ETHTOOL_GET_TS_INFO;
>  
> -	if (phy_has_tsinfo(phydev))
> -		return phy_ts_info(phydev, info);
> -	if (ops->get_ts_info)
> -		return ops->get_ts_info(dev, info);
> +	switch (dev->selected_timestamping_layer) {
> +	case MAC_TIMESTAMPING:
> +		if (ops->get_ts_info)
> +			return ops->get_ts_info(dev, info);
> +		break;
> +
> +	case PHY_TIMESTAMPING:
> +		if (phy_has_tsinfo(phydev))
> +			return phy_ts_info(phydev, info);
> +		WARN_ON(1);
> +		return -ENODEV;

same

> +	}
>  
>  	info->so_timestamping = SOF_TIMESTAMPING_RX_SOFTWARE |
>  				SOF_TIMESTAMPING_SOFTWARE;
  

Hi Köry,

I love your patch! Perhaps something to improve:

[auto build test WARNING on v6.2]
[cannot apply to robh/for-next horms-ipvs/master net/master net-next/master linus/master v6.3-rc1 next-20230308]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/K-ry-Maincent/net-ethtool-Refactor-identical-get_ts_info-implementations/20230308-220453
patch link:    https://lore.kernel.org/r/20230308135936.761794-4-kory.maincent%40bootlin.com
patch subject: [PATCH v3 3/5] net: Let the active time stamping layer be selectable.
config: riscv-allmodconfig (https://download.01.org/0day-ci/archive/20230309/202303090220.EervgFvH-lkp@intel.com/config)
compiler: riscv64-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/intel-lab-lkp/linux/commit/d81a36f239360e7e3b9ca2633e52b3cb12205590
        git remote add linux-review https://github.com/intel-lab-lkp/linux
        git fetch --no-tags linux-review K-ry-Maincent/net-ethtool-Refactor-identical-get_ts_info-implementations/20230308-220453
        git checkout d81a36f239360e7e3b9ca2633e52b3cb12205590
        # save the config file
        mkdir build_dir && cp config build_dir/.config
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=riscv olddefconfig
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=riscv SHELL=/bin/bash drivers/net/phy/

If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
| Link: https://lore.kernel.org/oe-kbuild-all/202303090220.EervgFvH-lkp@intel.com/

All warnings (new ones prefixed by >>):

>> drivers/net/phy/phy_device.c:1384:6: warning: no previous prototype for 'of_set_timestamp' [-Wmissing-prototypes]
    1384 | void of_set_timestamp(struct net_device *netdev, struct phy_device *phydev)
         |      ^~~~~~~~~~~~~~~~


vim +/of_set_timestamp +1384 drivers/net/phy/phy_device.c

  1383	
> 1384	void of_set_timestamp(struct net_device *netdev, struct phy_device *phydev)
  1385	{
  1386		struct device_node *node = phydev->mdio.dev.of_node;
  1387		const struct ethtool_ops *ops = netdev->ethtool_ops;
  1388		const char *s;
  1389		enum timestamping_layer ts_layer = 0;
  1390	
  1391		if (phy_has_hwtstamp(phydev))
  1392			ts_layer = PHY_TIMESTAMPING;
  1393		else if (ops->get_ts_info)
  1394			ts_layer = MAC_TIMESTAMPING;
  1395	
  1396		if (of_property_read_string(node, "preferred-timestamp", &s))
  1397			goto out;
  1398	
  1399		if (!s)
  1400			goto out;
  1401	
  1402		if (phy_has_hwtstamp(phydev) && !strcmp(s, "phy"))
  1403			ts_layer = PHY_TIMESTAMPING;
  1404	
  1405		if (ops->get_ts_info && !strcmp(s, "mac"))
  1406			ts_layer = MAC_TIMESTAMPING;
  1407	
  1408	out:
  1409		netdev->selected_timestamping_layer = ts_layer;
  1410	}
  1411
  

(trimmed CC list of bouncing email addresses)

On Wed, Mar 08, 2023 at 02:59:27PM +0100, Köry Maincent wrote:
> +void of_set_timestamp(struct net_device *netdev, struct phy_device *phydev)
> +{
> +	struct device_node *node = phydev->mdio.dev.of_node;
> +	const struct ethtool_ops *ops = netdev->ethtool_ops;
> +	const char *s;
> +	enum timestamping_layer ts_layer = 0;
> +
> +	if (phy_has_hwtstamp(phydev))
> +		ts_layer = PHY_TIMESTAMPING;
> +	else if (ops->get_ts_info)
> +		ts_layer = MAC_TIMESTAMPING;
> +
> +	if (of_property_read_string(node, "preferred-timestamp", &s))
> +		goto out;
> +
> +	if (!s)
> +		goto out;
> +
> +	if (phy_has_hwtstamp(phydev) && !strcmp(s, "phy"))
> +		ts_layer = PHY_TIMESTAMPING;
> +
> +	if (ops->get_ts_info && !strcmp(s, "mac"))
> +		ts_layer = MAC_TIMESTAMPING;
> +
> +out:
> +	netdev->selected_timestamping_layer = ts_layer;
> +}

From previous discussions, I believe that a device tree property was
added in order to prevent perceived performance regressions when
timestamping support is added to a PHY driver, correct?

I have a dumb question: if updating the device trees is needed in order
to prevent these behavior changes, then how is the regression problem
addressed for those device trees which don't contain this new property
(all device trees)?
  

Hi Köry,

I love your patch! Yet something to improve:

[auto build test ERROR on v6.2]
[cannot apply to robh/for-next horms-ipvs/master net/master net-next/master linus/master v6.3-rc1 next-20230309]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/K-ry-Maincent/net-ethtool-Refactor-identical-get_ts_info-implementations/20230308-220453
patch link:    https://lore.kernel.org/r/20230308135936.761794-4-kory.maincent%40bootlin.com
patch subject: [PATCH v3 3/5] net: Let the active time stamping layer be selectable.
config: um-i386_defconfig (https://download.01.org/0day-ci/archive/20230309/202303091304.yj8NySNz-lkp@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-8) 11.3.0
reproduce (this is a W=1 build):
        # https://github.com/intel-lab-lkp/linux/commit/d81a36f239360e7e3b9ca2633e52b3cb12205590
        git remote add linux-review https://github.com/intel-lab-lkp/linux
        git fetch --no-tags linux-review K-ry-Maincent/net-ethtool-Refactor-identical-get_ts_info-implementations/20230308-220453
        git checkout d81a36f239360e7e3b9ca2633e52b3cb12205590
        # save the config file
        mkdir build_dir && cp config build_dir/.config
        make W=1 O=build_dir ARCH=um SUBARCH=i386 olddefconfig
        make W=1 O=build_dir ARCH=um SUBARCH=i386 SHELL=/bin/bash

If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
| Link: https://lore.kernel.org/oe-kbuild-all/202303091304.yj8NySNz-lkp@intel.com/

All errors (new ones prefixed by >>):

   /usr/bin/ld: warning: arch/x86/um/checksum_32.o: missing .note.GNU-stack section implies executable stack
   /usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
   /usr/bin/ld: warning: .tmp_vmlinux.kallsyms1 has a LOAD segment with RWX permissions
   /usr/bin/ld: net/core/dev_ioctl.o: in function `dev_hwtstamp_ioctl':
   net/core/dev_ioctl.c:280: undefined reference to `phy_do_ioctl'
>> /usr/bin/ld: net/core/dev_ioctl.c:290: undefined reference to `phy_mii_ioctl'
   collect2: error: ld returned 1 exit status
  

Hi Köry,

I love your patch! Perhaps something to improve:

[auto build test WARNING on v6.2]
[cannot apply to robh/for-next horms-ipvs/master net/master net-next/master linus/master v6.3-rc1 next-20230309]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/K-ry-Maincent/net-ethtool-Refactor-identical-get_ts_info-implementations/20230308-220453
patch link:    https://lore.kernel.org/r/20230308135936.761794-4-kory.maincent%40bootlin.com
patch subject: [PATCH v3 3/5] net: Let the active time stamping layer be selectable.
config: x86_64-randconfig-a003 (https://download.01.org/0day-ci/archive/20230310/202303100154.iqj4R4fL-lkp@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/intel-lab-lkp/linux/commit/d81a36f239360e7e3b9ca2633e52b3cb12205590
        git remote add linux-review https://github.com/intel-lab-lkp/linux
        git fetch --no-tags linux-review K-ry-Maincent/net-ethtool-Refactor-identical-get_ts_info-implementations/20230308-220453
        git checkout d81a36f239360e7e3b9ca2633e52b3cb12205590
        # save the config file
        mkdir build_dir && cp config build_dir/.config
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=x86_64 olddefconfig
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/net/phy/

If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
| Link: https://lore.kernel.org/oe-kbuild-all/202303100154.iqj4R4fL-lkp@intel.com/

All warnings (new ones prefixed by >>):

>> drivers/net/phy/phy_device.c:1384:6: warning: no previous prototype for function 'of_set_timestamp' [-Wmissing-prototypes]
   void of_set_timestamp(struct net_device *netdev, struct phy_device *phydev)
        ^
   drivers/net/phy/phy_device.c:1384:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   void of_set_timestamp(struct net_device *netdev, struct phy_device *phydev)
   ^
   static 
   1 warning generated.


vim +/of_set_timestamp +1384 drivers/net/phy/phy_device.c

  1383	
> 1384	void of_set_timestamp(struct net_device *netdev, struct phy_device *phydev)
  1385	{
  1386		struct device_node *node = phydev->mdio.dev.of_node;
  1387		const struct ethtool_ops *ops = netdev->ethtool_ops;
  1388		const char *s;
  1389		enum timestamping_layer ts_layer = 0;
  1390	
  1391		if (phy_has_hwtstamp(phydev))
  1392			ts_layer = PHY_TIMESTAMPING;
  1393		else if (ops->get_ts_info)
  1394			ts_layer = MAC_TIMESTAMPING;
  1395	
  1396		if (of_property_read_string(node, "preferred-timestamp", &s))
  1397			goto out;
  1398	
  1399		if (!s)
  1400			goto out;
  1401	
  1402		if (phy_has_hwtstamp(phydev) && !strcmp(s, "phy"))
  1403			ts_layer = PHY_TIMESTAMPING;
  1404	
  1405		if (ops->get_ts_info && !strcmp(s, "mac"))
  1406			ts_layer = MAC_TIMESTAMPING;
  1407	
  1408	out:
  1409		netdev->selected_timestamping_layer = ts_layer;
  1410	}
  1411
  

Hello Vladimir,

On Thu, 9 Mar 2023 01:03:21 +0200
Vladimir Oltean <vladimir.oltean@nxp.com> wrote:

> (trimmed CC list of bouncing email addresses)
  
Thanks, I will be more careful on next patch series version.
 
> From previous discussions, I believe that a device tree property was
> added in order to prevent perceived performance regressions when
> timestamping support is added to a PHY driver, correct?

Yes, i.e. to select the default and better timestamp on a board.
 
> I have a dumb question: if updating the device trees is needed in order
> to prevent these behavior changes, then how is the regression problem
> addressed for those device trees which don't contain this new property
> (all device trees)?

On that case there is not really solution, but be aware that
CONFIG_PHY_TIMESTAMPING need to be activated to allow timestamping on the PHY.
Currently in mainline only few (3) defconfig have it enabled so it is really
not spread, maybe I could add more documentation to prevent further regression
issue when adding support of timestamp to a PHY driver.

Regards,
Köry
  

On Fri, Mar 10, 2023 at 11:48:52AM +0100, Köry Maincent wrote:
> > From previous discussions, I believe that a device tree property was
> > added in order to prevent perceived performance regressions when
> > timestamping support is added to a PHY driver, correct?
> 
> Yes, i.e. to select the default and better timestamp on a board.

Is there a way to unambiguously determine the "better" timestamping on a board?

Is it plausible that over time, when PTP timestamping matures and,
for example, MDIO devices get support for PTP_SYS_OFFSET_EXTENDED
(an attempt was here: https://lkml.org/lkml/2019/8/16/638), the
relationship between PTP clock qualities changes, and so does the
preference change?

> > I have a dumb question: if updating the device trees is needed in order
> > to prevent these behavior changes, then how is the regression problem
> > addressed for those device trees which don't contain this new property
> > (all device trees)?
> 
> On that case there is not really solution,

If it's not really a solution, then doesn't this fail at its primary
purpose of preventing regressions?

> but be aware that CONFIG_PHY_TIMESTAMPING need to be activated to
> allow timestamping on the PHY. Currently in mainline only few (3)
> defconfig have it enabled so it is really not spread,

Do distribution kernels use the defconfigs from the kernel, or do they
just enable as many options that sound good as possible?

> maybe I could add more documentation to prevent further regression
> issue when adding support of timestamp to a PHY driver.

My opinion is that either the problem was not correctly identified,
or the proposed solution does not address that problem.

What I believe is the problem is that adding support for PHY timestamping
to a PHY driver will cause a behavior change for existing systems which
are deployed with that PHY.

If I had a multi-port NIC where all ports share the same PHC, I would
want to create a boundary clock with it. I can do that just fine when
using MAC timestamping. But assume someone adds support for PHY
timestamping and the kernel switches to using PHY timestamps by default.
Now I need to keep in sync the PHCs of the PHYs, something which was
implicit before (all ports shared the same PHC). I have done nothing
incorrectly, yet my deployment doesn't work anymore. This is just an
example. It doesn't sound like a good idea in general for new features
to cause a behavior change by default.

Having identified that as the problem, I guess the solution should be
to stop doing that (and even though a PHY driver supports timestamping,
keep using the MAC timestamping by default).

There is a slight inconvenience caused by the fact that there are
already PHY drivers using PHY timestamping, and those may have been
introduced into deployments with PHY timestamping. We cannot change the
default behavior for those either. There are 5 such PHY drivers today
(I've grepped for mii_timestamper in drivers/net/phy).

I would suggest that the kernel implements a short whitelist of 5
entries containing PHY driver names, which are compared against
netdev->phydev->drv->name (with the appropriate NULL pointer checks).
Matches will default to PHY timestamping. Otherwise, the new default
will be to keep the behavior as if PHY timestamping doesn't exist
(MAC still provides the timestamps), and the user needs to select the
PHY as the timestamping source explicitly.

Thoughts?
  

[+ Horatiu]

Am 2023-03-10 12:35, schrieb Vladimir Oltean:
> On Fri, Mar 10, 2023 at 11:48:52AM +0100, Köry Maincent wrote:
>> > From previous discussions, I believe that a device tree property was
>> > added in order to prevent perceived performance regressions when
>> > timestamping support is added to a PHY driver, correct?
>> 
>> Yes, i.e. to select the default and better timestamp on a board.
> 
> Is there a way to unambiguously determine the "better" timestamping on 
> a board?
> 
> Is it plausible that over time, when PTP timestamping matures and,
> for example, MDIO devices get support for PTP_SYS_OFFSET_EXTENDED
> (an attempt was here: https://lkml.org/lkml/2019/8/16/638), the
> relationship between PTP clock qualities changes, and so does the
> preference change?
> 
>> > I have a dumb question: if updating the device trees is needed in order
>> > to prevent these behavior changes, then how is the regression problem
>> > addressed for those device trees which don't contain this new property
>> > (all device trees)?
>> 
>> On that case there is not really solution,
> 
> If it's not really a solution, then doesn't this fail at its primary
> purpose of preventing regressions?
> 
>> but be aware that CONFIG_PHY_TIMESTAMPING need to be activated to
>> allow timestamping on the PHY. Currently in mainline only few (3)
>> defconfig have it enabled so it is really not spread,
> 
> Do distribution kernels use the defconfigs from the kernel, or do they
> just enable as many options that sound good as possible?
> 
>> maybe I could add more documentation to prevent further regression
>> issue when adding support of timestamp to a PHY driver.
> 
> My opinion is that either the problem was not correctly identified,
> or the proposed solution does not address that problem.
> 
> What I believe is the problem is that adding support for PHY 
> timestamping
> to a PHY driver will cause a behavior change for existing systems which
> are deployed with that PHY.
> 
> If I had a multi-port NIC where all ports share the same PHC, I would
> want to create a boundary clock with it. I can do that just fine when
> using MAC timestamping. But assume someone adds support for PHY
> timestamping and the kernel switches to using PHY timestamps by 
> default.
> Now I need to keep in sync the PHCs of the PHYs, something which was
> implicit before (all ports shared the same PHC). I have done nothing
> incorrectly, yet my deployment doesn't work anymore. This is just an
> example. It doesn't sound like a good idea in general for new features
> to cause a behavior change by default.
> 
> Having identified that as the problem, I guess the solution should be
> to stop doing that (and even though a PHY driver supports timestamping,
> keep using the MAC timestamping by default).
> 
> There is a slight inconvenience caused by the fact that there are
> already PHY drivers using PHY timestamping, and those may have been
> introduced into deployments with PHY timestamping. We cannot change the
> default behavior for those either. There are 5 such PHY drivers today
> (I've grepped for mii_timestamper in drivers/net/phy).
> 
> I would suggest that the kernel implements a short whitelist of 5
> entries containing PHY driver names, which are compared against
> netdev->phydev->drv->name (with the appropriate NULL pointer checks).
> Matches will default to PHY timestamping. Otherwise, the new default
> will be to keep the behavior as if PHY timestamping doesn't exist
> (MAC still provides the timestamps), and the user needs to select the
> PHY as the timestamping source explicitly.
> 
> Thoughts?

While I agree in principle (I have suggested to make MAC timestamping
the default before), I see a problem with the recent LAN8814 PHY
timestamping support, which will likely be released with 6.3. That
would now switch the timestamping to PHY timestamping for our board
(arch/arm/boot/dts/lan966x-kontron-kswitch-d10-mmt-8g.dts). I could
argue that is a regression for our board iff NETWORK_PHY_TIMESTAMPING
is enabled. Honestly, I don't know how to proceed here and haven't
tried to replicate the regression due to limited time. Assuming,
that I can show it is a regression, what would be the solution then,
reverting the commit? Horatiu, any ideas?

I digress from the original problem a bit. But if there would be such
a whitelist, I'd propose that it won't contain the lan8814 driver.

Other than that, I guess I have to put some time into testing
before it's too late.

-michael
  

The 03/10/2023 13:15, Michael Walle wrote:
> 
> [+ Horatiu]
> 
> Am 2023-03-10 12:35, schrieb Vladimir Oltean:
> > On Fri, Mar 10, 2023 at 11:48:52AM +0100, Köry Maincent wrote:
> > > > From previous discussions, I believe that a device tree property was
> > > > added in order to prevent perceived performance regressions when
> > > > timestamping support is added to a PHY driver, correct?
> > > 
> > > Yes, i.e. to select the default and better timestamp on a board.
> > 
> > Is there a way to unambiguously determine the "better" timestamping on
> > a board?
> > 
> > Is it plausible that over time, when PTP timestamping matures and,
> > for example, MDIO devices get support for PTP_SYS_OFFSET_EXTENDED
> > (an attempt was here: https://lkml.org/lkml/2019/8/16/638), the
> > relationship between PTP clock qualities changes, and so does the
> > preference change?
> > 
> > > > I have a dumb question: if updating the device trees is needed in order
> > > > to prevent these behavior changes, then how is the regression problem
> > > > addressed for those device trees which don't contain this new property
> > > > (all device trees)?
> > > 
> > > On that case there is not really solution,
> > 
> > If it's not really a solution, then doesn't this fail at its primary
> > purpose of preventing regressions?
> > 
> > > but be aware that CONFIG_PHY_TIMESTAMPING need to be activated to
> > > allow timestamping on the PHY. Currently in mainline only few (3)
> > > defconfig have it enabled so it is really not spread,
> > 
> > Do distribution kernels use the defconfigs from the kernel, or do they
> > just enable as many options that sound good as possible?
> > 
> > > maybe I could add more documentation to prevent further regression
> > > issue when adding support of timestamp to a PHY driver.
> > 
> > My opinion is that either the problem was not correctly identified,
> > or the proposed solution does not address that problem.
> > 
> > What I believe is the problem is that adding support for PHY
> > timestamping
> > to a PHY driver will cause a behavior change for existing systems which
> > are deployed with that PHY.
> > 
> > If I had a multi-port NIC where all ports share the same PHC, I would
> > want to create a boundary clock with it. I can do that just fine when
> > using MAC timestamping. But assume someone adds support for PHY
> > timestamping and the kernel switches to using PHY timestamps by
> > default.
> > Now I need to keep in sync the PHCs of the PHYs, something which was
> > implicit before (all ports shared the same PHC). I have done nothing
> > incorrectly, yet my deployment doesn't work anymore. This is just an
> > example. It doesn't sound like a good idea in general for new features
> > to cause a behavior change by default.
> > 
> > Having identified that as the problem, I guess the solution should be
> > to stop doing that (and even though a PHY driver supports timestamping,
> > keep using the MAC timestamping by default).
> > 
> > There is a slight inconvenience caused by the fact that there are
> > already PHY drivers using PHY timestamping, and those may have been
> > introduced into deployments with PHY timestamping. We cannot change the
> > default behavior for those either. There are 5 such PHY drivers today
> > (I've grepped for mii_timestamper in drivers/net/phy).
> > 
> > I would suggest that the kernel implements a short whitelist of 5
> > entries containing PHY driver names, which are compared against
> > netdev->phydev->drv->name (with the appropriate NULL pointer checks).
> > Matches will default to PHY timestamping. Otherwise, the new default
> > will be to keep the behavior as if PHY timestamping doesn't exist
> > (MAC still provides the timestamps), and the user needs to select the
> > PHY as the timestamping source explicitly.
> > 
> > Thoughts?
> 
> While I agree in principle (I have suggested to make MAC timestamping
> the default before), I see a problem with the recent LAN8814 PHY
> timestamping support, which will likely be released with 6.3. That
> would now switch the timestamping to PHY timestamping for our board
> (arch/arm/boot/dts/lan966x-kontron-kswitch-d10-mmt-8g.dts). I could
> argue that is a regression for our board iff NETWORK_PHY_TIMESTAMPING
> is enabled. Honestly, I don't know how to proceed here and haven't
> tried to replicate the regression due to limited time. Assuming,
> that I can show it is a regression, what would be the solution then,
> reverting the commit? Horatiu, any ideas?

I don't think reverting the commit is the best approach. Because this
will block adding any timestamp support to any of the existing PHYs.
Maybe a better solution is to enable or disable NETWORK_PHY_TIMESTAMPING
depending where you want to do the timestamp.

> 
> I digress from the original problem a bit. But if there would be such
> a whitelist, I'd propose that it won't contain the lan8814 driver.

I don't have anything against having a whitelist the PHY driver names.

> 
> Other than that, I guess I have to put some time into testing
> before it's too late.

I was thinking about another scenario (I am sorry if this was already
discussed).
Currently when setting up to do the timestamp, the MAC will check if the
PHY has timestamping support if that is the case the PHY will do the
timestamping. So in case the switch was supposed to be a TC then we had
to make sure that the HW was setting up some rules not to forward PTP
frames by HW but to copy these frames to CPU.
With this new implementation, this would not be possible anymore as the
MAC will not be notified when doing the timestamping in the PHY.
Does it mean that now the switch should allocate these rules at start
time?

> 
> -michael
  

>> > > > From previous discussions, I believe that a device tree property was
>> > > > added in order to prevent perceived performance regressions when
>> > > > timestamping support is added to a PHY driver, correct?
>> > >
>> > > Yes, i.e. to select the default and better timestamp on a board.
>> >
>> > Is there a way to unambiguously determine the "better" timestamping on
>> > a board?
>> >
>> > Is it plausible that over time, when PTP timestamping matures and,
>> > for example, MDIO devices get support for PTP_SYS_OFFSET_EXTENDED
>> > (an attempt was here: https://lkml.org/lkml/2019/8/16/638), the
>> > relationship between PTP clock qualities changes, and so does the
>> > preference change?
>> >
>> > > > I have a dumb question: if updating the device trees is needed in order
>> > > > to prevent these behavior changes, then how is the regression problem
>> > > > addressed for those device trees which don't contain this new property
>> > > > (all device trees)?
>> > >
>> > > On that case there is not really solution,
>> >
>> > If it's not really a solution, then doesn't this fail at its primary
>> > purpose of preventing regressions?
>> >
>> > > but be aware that CONFIG_PHY_TIMESTAMPING need to be activated to
>> > > allow timestamping on the PHY. Currently in mainline only few (3)
>> > > defconfig have it enabled so it is really not spread,
>> >
>> > Do distribution kernels use the defconfigs from the kernel, or do they
>> > just enable as many options that sound good as possible?
>> >
>> > > maybe I could add more documentation to prevent further regression
>> > > issue when adding support of timestamp to a PHY driver.
>> >
>> > My opinion is that either the problem was not correctly identified,
>> > or the proposed solution does not address that problem.
>> >
>> > What I believe is the problem is that adding support for PHY
>> > timestamping
>> > to a PHY driver will cause a behavior change for existing systems which
>> > are deployed with that PHY.
>> >
>> > If I had a multi-port NIC where all ports share the same PHC, I would
>> > want to create a boundary clock with it. I can do that just fine when
>> > using MAC timestamping. But assume someone adds support for PHY
>> > timestamping and the kernel switches to using PHY timestamps by
>> > default.
>> > Now I need to keep in sync the PHCs of the PHYs, something which was
>> > implicit before (all ports shared the same PHC). I have done nothing
>> > incorrectly, yet my deployment doesn't work anymore. This is just an
>> > example. It doesn't sound like a good idea in general for new features
>> > to cause a behavior change by default.
>> >
>> > Having identified that as the problem, I guess the solution should be
>> > to stop doing that (and even though a PHY driver supports timestamping,
>> > keep using the MAC timestamping by default).
>> >
>> > There is a slight inconvenience caused by the fact that there are
>> > already PHY drivers using PHY timestamping, and those may have been
>> > introduced into deployments with PHY timestamping. We cannot change the
>> > default behavior for those either. There are 5 such PHY drivers today
>> > (I've grepped for mii_timestamper in drivers/net/phy).
>> >
>> > I would suggest that the kernel implements a short whitelist of 5
>> > entries containing PHY driver names, which are compared against
>> > netdev->phydev->drv->name (with the appropriate NULL pointer checks).
>> > Matches will default to PHY timestamping. Otherwise, the new default
>> > will be to keep the behavior as if PHY timestamping doesn't exist
>> > (MAC still provides the timestamps), and the user needs to select the
>> > PHY as the timestamping source explicitly.
>> >
>> > Thoughts?
>> 
>> While I agree in principle (I have suggested to make MAC timestamping
>> the default before), I see a problem with the recent LAN8814 PHY
>> timestamping support, which will likely be released with 6.3. That
>> would now switch the timestamping to PHY timestamping for our board
>> (arch/arm/boot/dts/lan966x-kontron-kswitch-d10-mmt-8g.dts). I could
>> argue that is a regression for our board iff NETWORK_PHY_TIMESTAMPING
>> is enabled. Honestly, I don't know how to proceed here and haven't
>> tried to replicate the regression due to limited time. Assuming,
>> that I can show it is a regression, what would be the solution then,
>> reverting the commit? Horatiu, any ideas?
> 
> I don't think reverting the commit is the best approach.

I didn't expect any other answer from the author of the patch ;)

> Because this
> will block adding any timestamp support to any of the existing PHYs.

Right, but if I understand it correctly, that is what has happend to
the Marvell PHY PTP support
https://lore.kernel.org/netdev/Y%2FzKJUHUhEgXjKFG@shell.armlinux.org.uk/

(Or it was NAK'ed before it could even get in. Maybe I'm to blame here,
but I have just so much time to follow all the mainline development).

> Maybe a better solution is to enable or disable 
> NETWORK_PHY_TIMESTAMPING
> depending where you want to do the timestamp.

No, that is not how this can work. I agree with Vladimir, that in
general, you have no control which kernel options are enabled, see
distros.

>> I digress from the original problem a bit. But if there would be such
>> a whitelist, I'd propose that it won't contain the lan8814 driver.
> 
> I don't have anything against having a whitelist the PHY driver names.

Yeah, but my problem right now is, that if this discussion won't find
any good solution, the lan8814 phy timestamping will find it's way
into an official kernel and then it is really hard to undo things.

So, I'd really prefer to *first* have a discussion how to proceed
with the PHY timestamping and then add the lan8814 support, so
existing boards don't show a regressions.

-michael
  

On Fri, 10 Mar 2023 14:34:07 +0100
Michael Walle <michael@walle.cc> wrote:

> >> > There is a slight inconvenience caused by the fact that there are
> >> > already PHY drivers using PHY timestamping, and those may have been
> >> > introduced into deployments with PHY timestamping. We cannot change the
> >> > default behavior for those either. There are 5 such PHY drivers today
> >> > (I've grepped for mii_timestamper in drivers/net/phy).
> >> >
> >> > I would suggest that the kernel implements a short whitelist of 5
> >> > entries containing PHY driver names, which are compared against
> >> > netdev->phydev->drv->name (with the appropriate NULL pointer checks).
> >> > Matches will default to PHY timestamping. Otherwise, the new default
> >> > will be to keep the behavior as if PHY timestamping doesn't exist
> >> > (MAC still provides the timestamps), and the user needs to select the
> >> > PHY as the timestamping source explicitly.
> >> >
> >> > Thoughts?  
> >> 
> >> While I agree in principle (I have suggested to make MAC timestamping
> >> the default before), I see a problem with the recent LAN8814 PHY
> >> timestamping support, which will likely be released with 6.3. That
> >> would now switch the timestamping to PHY timestamping for our board
> >> (arch/arm/boot/dts/lan966x-kontron-kswitch-d10-mmt-8g.dts). I could
> >> argue that is a regression for our board iff NETWORK_PHY_TIMESTAMPING
> >> is enabled. Honestly, I don't know how to proceed here and haven't
> >> tried to replicate the regression due to limited time. Assuming,
> >> that I can show it is a regression, what would be the solution then,
> >> reverting the commit? Horatiu, any ideas?

Adding this whitelist will add some PHY driver specific name in the phy API
core.
Will it be accepted? Is it not better to add a "legacy_default_timestamping"
boolean in the phy_device struct and set it for these 5 PHY drivers?
Then move on the default behavior to MAC default timestamping on the otehr
cases.
 
> >> I digress from the original problem a bit. But if there would be such
> >> a whitelist, I'd propose that it won't contain the lan8814 driver.  
> > 
> > I don't have anything against having a whitelist the PHY driver names.  
> 
> Yeah, but my problem right now is, that if this discussion won't find
> any good solution, the lan8814 phy timestamping will find it's way
> into an official kernel and then it is really hard to undo things.

Yes and we need to find a solution as the issue will raise at each new PHY PTP
support.

Köry
  

On Wed, 08 Mar 2023 10:28:51 -0500
Willem de Bruijn <willemdebruijn.kernel@gmail.com> wrote:

> >  
> > +	enum timestamping_layer selected_timestamping_layer;
> > +  
> 
> can perhaps be a single bit rather than an enum

I need at least two bits to be able to list the PTPs available.
Look at the ethtool_list_ptp function of the second patch.

> > +			err = -ENODEV;
> > +			WARN_ON(1);  
> 
> Please no WARN_ON on error cases that are known to be reachable
> and can be handled safely and reported to userspace.

Alright, thanks.

Köry
  

Köry Maincent wrote:
> On Wed, 08 Mar 2023 10:28:51 -0500
> Willem de Bruijn <willemdebruijn.kernel@gmail.com> wrote:
> 
> > >  
> > > +	enum timestamping_layer selected_timestamping_layer;
> > > +  
> > 
> > can perhaps be a single bit rather than an enum
> 
> I need at least two bits to be able to list the PTPs available.
> Look at the ethtool_list_ptp function of the second patch.

In the available bitmap, yes. Since there are only two options,
in the selected case, a single bit would suffice.
  

On Fri, Mar 10, 2023 at 03:04:36PM +0100, Köry Maincent wrote:

> Adding this whitelist will add some PHY driver specific name in the phy API
> core.
> Will it be accepted? Is it not better to add a "legacy_default_timestamping"
> boolean in the phy_device struct and set it for these 5 PHY drivers?
> Then move on the default behavior to MAC default timestamping on the otehr
> cases.

This sounds okay to me.  @Russell will that work for your board?

Thanks,
Richard
  

> Adding this whitelist will add some PHY driver specific name in the phy API
> core.
> Will it be accepted? Is it not better to add a "legacy_default_timestamping"
> boolean in the phy_device struct and set it for these 5 PHY drivers?
> Then move on the default behavior to MAC default timestamping on the otehr
> cases.

In the end, it is much the same thing. But if we really want this to
be legacy, not used by new drivers, putting it into the core will make
it harder for new drivers to set this bit and not get noticed during
review.

   Andrew
  

On Fri, Mar 10, 2023 at 09:59:53AM -0500, Willem de Bruijn wrote:
> Köry Maincent wrote:
> > On Wed, 08 Mar 2023 10:28:51 -0500
> > Willem de Bruijn <willemdebruijn.kernel@gmail.com> wrote:
> > 
> > > >  
> > > > +	enum timestamping_layer selected_timestamping_layer;
> > > > +  
> > > 
> > > can perhaps be a single bit rather than an enum
> > 
> > I need at least two bits to be able to list the PTPs available.
> > Look at the ethtool_list_ptp function of the second patch.
> 
> In the available bitmap, yes. Since there are only two options,
> in the selected case, a single bit would suffice.

It was a bit tongue in cheek, but in an earlier thread discussing this
problem, i listed how there could be up to 7 time stampers on the path
from the RJ45 to the network stack.

We got into this problem by assuming there could only ever be one time
stamper. Lets try to avoid potential problems of assuming there can
only every be two time stampers by assuming there can be N stampers.

     Andrew
  

On Fri, Mar 10, 2023 at 02:34:07PM +0100, Michael Walle wrote:
> Yeah, but my problem right now is, that if this discussion won't find
> any good solution, the lan8814 phy timestamping will find it's way
> into an official kernel and then it is really hard to undo things.
> 
> So, I'd really prefer to *first* have a discussion how to proceed
> with the PHY timestamping and then add the lan8814 support, so
> existing boards don't show a regressions.

You don't mean LAN8814 but LAN8841, no?

For the former, PTP support was added in commit ece19502834d ("net: phy:
micrel: 1588 support for LAN8814 phy") - first present in v5.18.

For the latter, it was commit cafc3662ee3f ("net: micrel: Add PHC
support for lan8841"), and this one indeed is in the v6.3 release
candidates.

Assuming you can prove a regression, how about adding the PHY driver
whitelist *without* the lan8841 as a patch to net.git? (blaming commit
cafc3662ee3f ("net: micrel: Add PHC support for lan8841")).

Doing this will effectively deactivate lan8841 PHY timestamping without
reverting the code. Then, this PHY timestamping support could be
activated back in net-next, based on some sort of explicit UAPI call.
  

On Fri, Mar 10, 2023 at 02:15:29PM +0100, Horatiu Vultur wrote:
> I was thinking about another scenario (I am sorry if this was already
> discussed).
> Currently when setting up to do the timestamp, the MAC will check if the
> PHY has timestamping support if that is the case the PHY will do the
> timestamping. So in case the switch was supposed to be a TC then we had
> to make sure that the HW was setting up some rules not to forward PTP
> frames by HW but to copy these frames to CPU.
> With this new implementation, this would not be possible anymore as the
> MAC will not be notified when doing the timestamping in the PHY.
> Does it mean that now the switch should allocate these rules at start
> time?

I would say no (to the allocation of trapping rules at startup time).
It was argued before by people present in this thread that it should be
possible (and default behavior) for switches to forward PTP frames as if
they were PTP-unaware:
https://patchwork.ozlabs.org/project/netdev/patch/20190813025214.18601-5-yangbo.lu@nxp.com/

But it raises a really good point about how much care a switch driver
needs to take, such that with PTP timestamping, it must trap but not
timestamp the PTP frames.

There is a huge amount of variability here today.

The ocelot driver would be broken with PHY timestamping, since it would
flood the PTP messages (it installs the traps only if it is responsible
for taking the timestamps too).

The lan966x driver is very fine-tuned to call lan966x_ptp_setup_traps()
regardless of what phy_has_hwtstamp() says.

The sparx5 driver doesn't even seem to install traps at all (unclear if
they are predefined in hardware or not).

I guess that we want something like lan966x to keep working, since it
sounds like it's making the sanest decision about what to do.

But, as you point out, with Köry's/Richard's proposal, the MAC driver
will be bypassed when the selected timestamping layer is the PHY, and
that's a problem currently.

May I suggest the following? There was another RFC which proposed the
introduction of a netdev notifier when timestamping is turned on/off:
https://lore.kernel.org/netdev/20220317225035.3475538-1-vladimir.oltean@nxp.com/

It didn't go beyond RFC status, because I started doing what Jakub
suggested (converting the raw ioctls handlers to NDOs) but quickly got
absolutely swamped into the whole mess.

If we have a notifier, then we can make switch drivers do things
differently. They can activate timestamping per se in the timestamping
NDO (which is only called when the MAC is the active timestamping layer),
and they can activate PTP traps in the netdev notifier (which is called
any time a timestamping status change takes place - the notifier info
should contain details about which net_device and timestamping layer
this is, for example).

It's just a proposal of how to create an alternative notification path
that doesn't disturb the goals of this patch set.
  

Am 2023-03-10 17:06, schrieb Vladimir Oltean:
> On Fri, Mar 10, 2023 at 02:34:07PM +0100, Michael Walle wrote:
>> Yeah, but my problem right now is, that if this discussion won't find
>> any good solution, the lan8814 phy timestamping will find it's way
>> into an official kernel and then it is really hard to undo things.
>> 
>> So, I'd really prefer to *first* have a discussion how to proceed
>> with the PHY timestamping and then add the lan8814 support, so
>> existing boards don't show a regressions.
> 
> You don't mean LAN8814 but LAN8841, no?

Ohh, I'm stupid. No, I mean the LAN8814 (Quad PHY).

> For the former, PTP support was added in commit ece19502834d ("net: 
> phy:
> micrel: 1588 support for LAN8814 phy") - first present in v5.18.

Yeah and I remember.. there was some kind of issue with the PHY
latencies. Ok, looks like I'm screwed then. I wonder how Microchip
is doing it, because our board is almost an identical copy of the
reference system.

> For the latter, it was commit cafc3662ee3f ("net: micrel: Add PHC
> support for lan8841"), and this one indeed is in the v6.3 release
> candidates.
> 
> Assuming you can prove a regression, how about adding the PHY driver
> whitelist *without* the lan8841 as a patch to net.git? (blaming commit
> cafc3662ee3f ("net: micrel: Add PHC support for lan8841")).
> 
> Doing this will effectively deactivate lan8841 PHY timestamping without
> reverting the code. Then, this PHY timestamping support could be
> activated back in net-next, based on some sort of explicit UAPI call.

Sorry for the noise and any inconvenience,
-michael
  

The 03/10/2023 18:44, Vladimir Oltean wrote:
> 
> On Fri, Mar 10, 2023 at 02:15:29PM +0100, Horatiu Vultur wrote:
> > I was thinking about another scenario (I am sorry if this was already
> > discussed).
> > Currently when setting up to do the timestamp, the MAC will check if the
> > PHY has timestamping support if that is the case the PHY will do the
> > timestamping. So in case the switch was supposed to be a TC then we had
> > to make sure that the HW was setting up some rules not to forward PTP
> > frames by HW but to copy these frames to CPU.
> > With this new implementation, this would not be possible anymore as the
> > MAC will not be notified when doing the timestamping in the PHY.
> > Does it mean that now the switch should allocate these rules at start
> > time?
> 
> I would say no (to the allocation of trapping rules at startup time).
> It was argued before by people present in this thread that it should be
> possible (and default behavior) for switches to forward PTP frames as if
> they were PTP-unaware:
> https://patchwork.ozlabs.org/project/netdev/patch/20190813025214.18601-5-yangbo.lu@nxp.com/

Thanks for the explanation!

> 
> But it raises a really good point about how much care a switch driver
> needs to take, such that with PTP timestamping, it must trap but not
> timestamp the PTP frames.
> 
> There is a huge amount of variability here today.
> 
> The ocelot driver would be broken with PHY timestamping, since it would
> flood the PTP messages (it installs the traps only if it is responsible
> for taking the timestamps too).
> 
> The lan966x driver is very fine-tuned to call lan966x_ptp_setup_traps()
> regardless of what phy_has_hwtstamp() says.
> 
> The sparx5 driver doesn't even seem to install traps at all (unclear if
> they are predefined in hardware or not).

They are not predefined in HW, I have on my TODO list to add those
traps I just need to get the time to do this.

> 
> I guess that we want something like lan966x to keep working, since it
> sounds like it's making the sanest decision about what to do.
> 
> But, as you point out, with Köry's/Richard's proposal, the MAC driver
> will be bypassed when the selected timestamping layer is the PHY, and
> that's a problem currently.
> 
> May I suggest the following? There was another RFC which proposed the
> introduction of a netdev notifier when timestamping is turned on/off:
> https://lore.kernel.org/netdev/20220317225035.3475538-1-vladimir.oltean@nxp.com/
> 
> It didn't go beyond RFC status, because I started doing what Jakub
> suggested (converting the raw ioctls handlers to NDOs) but quickly got
> absolutely swamped into the whole mess.
> 
> If we have a notifier, then we can make switch drivers do things
> differently. They can activate timestamping per se in the timestamping
> NDO (which is only called when the MAC is the active timestamping layer),
> and they can activate PTP traps in the netdev notifier (which is called
> any time a timestamping status change takes place - the notifier info
> should contain details about which net_device and timestamping layer
> this is, for example).
> 
> It's just a proposal of how to create an alternative notification path
> that doesn't disturb the goals of this patch set.
  

On Fri, Mar 10, 2023 at 06:44:51PM +0200, Vladimir Oltean wrote:
> On Fri, Mar 10, 2023 at 02:15:29PM +0100, Horatiu Vultur wrote:
> > I was thinking about another scenario (I am sorry if this was already
> > discussed).
> > Currently when setting up to do the timestamp, the MAC will check if the
> > PHY has timestamping support if that is the case the PHY will do the
> > timestamping. So in case the switch was supposed to be a TC then we had
> > to make sure that the HW was setting up some rules not to forward PTP
> > frames by HW but to copy these frames to CPU.
> > With this new implementation, this would not be possible anymore as the
> > MAC will not be notified when doing the timestamping in the PHY.
> > Does it mean that now the switch should allocate these rules at start
> > time?
> 
> I would say no (to the allocation of trapping rules at startup time).
> It was argued before by people present in this thread that it should be
> possible (and default behavior) for switches to forward PTP frames as if
> they were PTP-unaware:
> https://patchwork.ozlabs.org/project/netdev/patch/20190813025214.18601-5-yangbo.lu@nxp.com/
> 
> But it raises a really good point about how much care a switch driver
> needs to take, such that with PTP timestamping, it must trap but not
> timestamp the PTP frames.
> 
> There is a huge amount of variability here today.
> 
> The ocelot driver would be broken with PHY timestamping, since it would
> flood the PTP messages (it installs the traps only if it is responsible
> for taking the timestamps too).
> 
> The lan966x driver is very fine-tuned to call lan966x_ptp_setup_traps()
> regardless of what phy_has_hwtstamp() says.
> 
> The sparx5 driver doesn't even seem to install traps at all (unclear if
> they are predefined in hardware or not).
> 
> I guess that we want something like lan966x to keep working, since it
> sounds like it's making the sanest decision about what to do.
> 
> But, as you point out, with Köry's/Richard's proposal, the MAC driver
> will be bypassed when the selected timestamping layer is the PHY, and
> that's a problem currently.
> 
> May I suggest the following? There was another RFC which proposed the
> introduction of a netdev notifier when timestamping is turned on/off:
> https://lore.kernel.org/netdev/20220317225035.3475538-1-vladimir.oltean@nxp.com/
> 
> It didn't go beyond RFC status, because I started doing what Jakub
> suggested (converting the raw ioctls handlers to NDOs) but quickly got
> absolutely swamped into the whole mess.
> 
> If we have a notifier, then we can make switch drivers do things
> differently. They can activate timestamping per se in the timestamping
> NDO (which is only called when the MAC is the active timestamping layer),
> and they can activate PTP traps in the netdev notifier (which is called
> any time a timestamping status change takes place - the notifier info
> should contain details about which net_device and timestamping layer
> this is, for example).
> 
> It's just a proposal of how to create an alternative notification path
> that doesn't disturb the goals of this patch set.

To make things even more complicated - I  have a project where the DSA master
should be used for time stamping. Due to board specific limitations, we
are forced to use FEC PHC instead of dsa KSZ switch PHC. So, it is not
a choice between MAC and PHY, it is more the MAC before MAC and PHY.
PTP sync in this case will have more jitter, but it still good enough
for this project.
Currently I use quick hack to do so, but mainlinamble solution working for
most use cases will be nice.

Regards,
Oleksij
  

On Mon, 13 Mar 2023 09:40:59 +0100
Oleksij Rempel <o.rempel@pengutronix.de> wrote:

> > But, as you point out, with Köry's/Richard's proposal, the MAC driver
> > will be bypassed when the selected timestamping layer is the PHY, and
> > that's a problem currently.
> > 
> > May I suggest the following? There was another RFC which proposed the
> > introduction of a netdev notifier when timestamping is turned on/off:
> > https://lore.kernel.org/netdev/20220317225035.3475538-1-vladimir.oltean@nxp.com/
> >
> > If we have a notifier, then we can make switch drivers do things
> > differently. They can activate timestamping per se in the timestamping
> > NDO (which is only called when the MAC is the active timestamping layer),
> > and they can activate PTP traps in the netdev notifier (which is called
> > any time a timestamping status change takes place - the notifier info
> > should contain details about which net_device and timestamping layer
> > this is, for example).
> > 
> > It's just a proposal of how to create an alternative notification path
> > that doesn't disturb the goals of this patch set. 

I will take a look at your patch but indeed adding a timestamp notifier could
be a good idea.

> To make things even more complicated - I  have a project where the DSA master
> should be used for time stamping. Due to board specific limitations, we
> are forced to use FEC PHC instead of dsa KSZ switch PHC. So, it is not
> a choice between MAC and PHY, it is more the MAC before MAC and PHY.
> PTP sync in this case will have more jitter, but it still good enough
> for this project.
> Currently I use quick hack to do so, but mainlinamble solution working for
> most use cases will be nice.

In this case it is not a PHY/MAC PTP choice anymore but more a device
PTP choice which bring a lot more of complexity. Or maybe we could simply add a
"switch" timestamp layer later on. As Andrew said we will maybe increase the
number of timestamp layers in the future.

Regards,
Köry
  

On Mon, 13 Mar 2023 09:40:59 +0100
Oleksij Rempel <o.rempel@pengutronix.de> wrote:

> > It didn't go beyond RFC status, because I started doing what Jakub
> > suggested (converting the raw ioctls handlers to NDOs) but quickly got
> > absolutely swamped into the whole mess.

Was there any useful work that could be continued on managing timestamp through
NDOs. As it seem we will made some change to the timestamp API, maybe it is a
good time to also take care of this.

Köry
  

On Thu, Mar 16, 2023 at 04:09:20PM +0100, Köry Maincent wrote:
> Was there any useful work that could be continued on managing timestamp through
> NDOs. As it seem we will made some change to the timestamp API, maybe it is a
> good time to also take care of this.

Not to my knowledge. Yes, I agree that it would be a good time to add an
NDO for hwtimestamping (while keeping the ioctl fallback), then
transitioning as many devices as we can, and removing the fallback when
the transition is complete.
  

On Fri, 17 Mar 2023 17:21:50 +0200 Vladimir Oltean wrote:
> On Thu, Mar 16, 2023 at 04:09:20PM +0100, Köry Maincent wrote:
> > Was there any useful work that could be continued on managing timestamp through
> > NDOs. As it seem we will made some change to the timestamp API, maybe it is a
> > good time to also take care of this.  
> 
> Not to my knowledge. Yes, I agree that it would be a good time to add an
> NDO for hwtimestamping (while keeping the ioctl fallback), then
> transitioning as many devices as we can, and removing the fallback when
> the transition is complete.

I believe Max was looking into it - hi Max! Did you make much
progress? Any code you could share to build on?
  

Jakub,

I started working on a patch introducing NDO functions for hw
timestamping, but unfortunately put it on hold.
Let me finish it and send it out for review.

On Fri, Mar 17, 2023 at 1:07 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Fri, 17 Mar 2023 17:21:50 +0200 Vladimir Oltean wrote:
> > On Thu, Mar 16, 2023 at 04:09:20PM +0100, Köry Maincent wrote:
> > > Was there any useful work that could be continued on managing timestamp through
> > > NDOs. As it seem we will made some change to the timestamp API, maybe it is a
> > > good time to also take care of this.
> >
> > Not to my knowledge. Yes, I agree that it would be a good time to add an
> > NDO for hwtimestamping (while keeping the ioctl fallback), then
> > transitioning as many devices as we can, and removing the fallback when
> > the transition is complete.
>
> I believe Max was looking into it - hi Max! Did you make much
> progress? Any code you could share to build on?
  

On Fri, Mar 17, 2023 at 05:21:50PM +0200, Vladimir Oltean wrote:
> On Thu, Mar 16, 2023 at 04:09:20PM +0100, Köry Maincent wrote:
> > Was there any useful work that could be continued on managing timestamp through
> > NDOs. As it seem we will made some change to the timestamp API, maybe it is a
> > good time to also take care of this.
> 
> Not to my knowledge. Yes, I agree that it would be a good time to add an
> NDO for hwtimestamping (while keeping the ioctl fallback), then
> transitioning as many devices as we can, and removing the fallback when
> the transition is complete.

Um, user space ABI cannot be removed.

Thanks,
Richard
  

On Fri, 17 Mar 2023 20:38:49 -0700 Richard Cochran wrote:
> On Fri, Mar 17, 2023 at 05:21:50PM +0200, Vladimir Oltean wrote:
> > On Thu, Mar 16, 2023 at 04:09:20PM +0100, Köry Maincent wrote:  
> > > Was there any useful work that could be continued on managing timestamp through
> > > NDOs. As it seem we will made some change to the timestamp API, maybe it is a
> > > good time to also take care of this.  
> > 
> > Not to my knowledge. Yes, I agree that it would be a good time to add an
> > NDO for hwtimestamping (while keeping the ioctl fallback), then
> > transitioning as many devices as we can, and removing the fallback when
> > the transition is complete.  
> 
> Um, user space ABI cannot be removed.

NDO meaning a dedicated callback in struct net_device_ops, so at least
for netdevs we can copy the data from user space, validate in the core
and then call the driver with a normal kernel pointer. So just an
internal refactoring, no uAPI changes.
  

On Fri, Mar 17, 2023 at 09:03:06PM -0700, Jakub Kicinski wrote:
> On Fri, 17 Mar 2023 20:38:49 -0700 Richard Cochran wrote:
> > On Fri, Mar 17, 2023 at 05:21:50PM +0200, Vladimir Oltean wrote:
> > > On Thu, Mar 16, 2023 at 04:09:20PM +0100, Köry Maincent wrote:  
> > > > Was there any useful work that could be continued on managing timestamp through
> > > > NDOs. As it seem we will made some change to the timestamp API, maybe it is a
> > > > good time to also take care of this.  
> > > 
> > > Not to my knowledge. Yes, I agree that it would be a good time to add an
> > > NDO for hwtimestamping (while keeping the ioctl fallback), then
> > > transitioning as many devices as we can, and removing the fallback when
> > > the transition is complete.  
> > 
> > Um, user space ABI cannot be removed.
> 
> NDO meaning a dedicated callback in struct net_device_ops, so at least
> for netdevs we can copy the data from user space, validate in the core
> and then call the driver with a normal kernel pointer. So just an
> internal refactoring, no uAPI changes.

Yes, I was talking about the current handling via net_device_ops :: ndo_eth_ioctl()
(internal driver-facing kernel API) that should eventually get removed.
The new ndo_hwtstamp_get() and ndo_hwtstamp_set() should also have
slightly different (clearer) semantics IMO, like for example they should
only get called if the selected timestamping layer is the MAC. The MAC
driver would no longer be concerned with marshalling these calls down to
the PHY for PHY timestamping with this new API.

This is also the reason why the conversion can't be realistically done
all at once, because in some cases, as pointed out by Horatiu, simply
marshalling the ndo_eth_ioctl() to phy_mii_ioctl() isn't the only thing
that's necessary - sometimes the MAC driver may need to add filters or
traps for PTP frames itself, even if it doesn't provide the timestamps
per se. That will be solved not via the ndo_hwtstamp_set(), but via a
new (listen-only) NETDEV_HWTSTAMP_SET notifier, where interested drivers
can figure out that timestamping was enabled somewhere along the data
path of their netdev (not necessarily at their MAC layer) and program
those filters or traps accordingly, so that either MAC, or PHY,
timestamping works properly e.g. on a switch.

Also, the ndo_hwtstamp_get() and ndo_hwtstamp_set() API should not need
to explicitly call copy_from_user() and copy_to_user(), those are
especially error-prone w.r.t. their error code - non-zero means "bytes
left to copy IIRC", but -EFAULT should be returned to user space,
instead of blindly propagating what copy_from_user() has returned.
  

Hello everyone,

I'm sorry to intervene late in this discussion, but since it looks like
the discussion is converging towards the creation of a new API (though
NDOs internally, and through netlink for userspace), I'd like to add a
small other use-case to consider. Of course, this can be addressed
later on.

On Fri, 10 Mar 2023 13:35:33 +0200
Vladimir Oltean <vladimir.oltean@nxp.com> wrote:

> On Fri, Mar 10, 2023 at 11:48:52AM +0100, Köry Maincent wrote:
> > > From previous discussions, I believe that a device tree property
> > > was added in order to prevent perceived performance regressions
> > > when timestamping support is added to a PHY driver, correct?  
> > 
> > Yes, i.e. to select the default and better timestamp on a board.  
> 
> Is there a way to unambiguously determine the "better" timestamping
> on a board?

I'd like to point out a series sent a while ago :

https://lore.kernel.org/netdev/3a14f417-1ae1-9434-5532-4b3387f25d18@orolia.com/

Here, the MAC's timestamping unit can be configured in 2 ways, which
boils down to either more accurate timestamps, or better accuracy in
frequency adjustments for the clock.

The need is to be able to change this mode at runtime, as we can change
the clock source for the timestamping unit to a very precise-one,
therefore using the "accurate timestamps mode" working as a
grand-master, or switching to slave mode, where we would sacrifice a
little bit the timestamping precision to get better frequency
precision.

So, we can consider here that not only the MAC's timestamping unit has
a non-fixed precision, but if we go through the route a a new API,
maybe we can also take this case into account, allowing for a bit of
configuration of the timestamping unit from userspace? 

> Is it plausible that over time, when PTP timestamping matures and,
> for example, MDIO devices get support for PTP_SYS_OFFSET_EXTENDED
> (an attempt was here: https://lkml.org/lkml/2019/8/16/638), the
> relationship between PTP clock qualities changes, and so does the
> preference change?

I'm not exactly familiar with PTP_SYS_OFFSET_EXTENDED, but it looks a
bit similar in purpose to the above-mentionned use-case.

Thanks,

Maxime
  

Hello Max,

On Fri, 17 Mar 2023 13:43:34 -0600
Max Georgiev <glipus@gmail.com> wrote:

> Jakub,
> 
> I started working on a patch introducing NDO functions for hw
> timestamping, but unfortunately put it on hold.
> Let me finish it and send it out for review.

What is your timeline for it? Do you think of sending it in the followings
weeks, months, years? If you don't have much time ask for help, I am not really
a PTP core expert but I would gladly work with you on this.

Köry
  

On Thu, 30 Mar 2023 14:38:24 +0200 Köry Maincent wrote:
> > I started working on a patch introducing NDO functions for hw
> > timestamping, but unfortunately put it on hold.
> > Let me finish it and send it out for review.  
> 
> What is your timeline for it? Do you think of sending it in the followings
> weeks, months, years? If you don't have much time ask for help, I am not really
> a PTP core expert but I would gladly work with you on this.

+1 Max, could you push what you have to GitHub or post as an RFC?
  

On Thu, Mar 30, 2023 at 10:26 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Thu, 30 Mar 2023 14:38:24 +0200 Köry Maincent wrote:
> > > I started working on a patch introducing NDO functions for hw
> > > timestamping, but unfortunately put it on hold.
> > > Let me finish it and send it out for review.
> >
> > What is your timeline for it? Do you think of sending it in the followings
> > weeks, months, years? If you don't have much time ask for help, I am not really
> > a PTP core expert but I would gladly work with you on this.
>
> +1 Max, could you push what you have to GitHub or post as an RFC?

I'm awfully sorry for the delay.

I've sent out what I had as an RFC to netdev list, the subject is
"[PATCH net-next RFC] Add NDOs for hardware timestamp get/set".
I'll continue working on testing the patch. Looking forward to
comments and suggestions.
  

On Thu, Mar 30, 2023 at 11:05 PM Max Georgiev <glipus@gmail.com> wrote:
>
> On Thu, Mar 30, 2023 at 10:26 AM Jakub Kicinski <kuba@kernel.org> wrote:
> >
> > On Thu, 30 Mar 2023 14:38:24 +0200 Köry Maincent wrote:
> > > > I started working on a patch introducing NDO functions for hw
> > > > timestamping, but unfortunately put it on hold.
> > > > Let me finish it and send it out for review.
> > >
> > > What is your timeline for it? Do you think of sending it in the followings
> > > weeks, months, years? If you don't have much time ask for help, I am not really
> > > a PTP core expert but I would gladly work with you on this.
> >
> > +1 Max, could you push what you have to GitHub or post as an RFC?
>
> I'm awfully sorry for the delay.
>
> I've sent out what I had as an RFC to netdev list, the subject is
> "[PATCH net-next RFC] Add NDOs for hardware timestamp get/set".
> I'll continue working on testing the patch. Looking forward to
> comments and suggestions.

Here is a link to the RFC patch:
https://lore.kernel.org/netdev/20230331045619.40256-1-glipus@gmail.com/
  

On Thu, Mar 30, 2023 at 02:38:24PM +0200, Köry Maincent wrote:
> Hello Max,
> 
> On Fri, 17 Mar 2023 13:43:34 -0600
> Max Georgiev <glipus@gmail.com> wrote:
> 
> > Jakub,
> > 
> > I started working on a patch introducing NDO functions for hw
> > timestamping, but unfortunately put it on hold.
> > Let me finish it and send it out for review.
> 
> What is your timeline for it? Do you think of sending it in the followings
> weeks, months, years? If you don't have much time ask for help, I am not really
> a PTP core expert but I would gladly work with you on this.

Köry, I believe you can start looking at that PHY driver whitelist
(for changing the default timestamping layer) in parallel with Maxim's
ndo_hwtstamp_set() effort, since they shouldn't depend on each other?
  

Hello Maxime,

On Fri, Mar 24, 2023 at 11:25:41AM +0100, Maxime Chevallier wrote:
> I'd like to point out a series sent a while ago :
> 
> https://lore.kernel.org/netdev/3a14f417-1ae1-9434-5532-4b3387f25d18@orolia.com/
> 
> Here, the MAC's timestamping unit can be configured in 2 ways, which
> boils down to either more accurate timestamps, or better accuracy in
> frequency adjustments for the clock.
> 
> The need is to be able to change this mode at runtime, as we can change
> the clock source for the timestamping unit to a very precise-one,
> therefore using the "accurate timestamps mode" working as a
> grand-master, or switching to slave mode, where we would sacrifice a
> little bit the timestamping precision to get better frequency
> precision.
> 
> So, we can consider here that not only the MAC's timestamping unit has
> a non-fixed precision, but if we go through the route a a new API,
> maybe we can also take this case into account, allowing for a bit of
> configuration of the timestamping unit from userspace?

How would you suggest that this API looks like, what would be there to
configure on the timestamping unit? You're not looking for something
specific like "fine vs coarse" to be accepted, I hope?

Perhaps the stmmac is patched to expose 2 PHCs, one for fine mode and
one for coarse mode, and the timestamping PHC selection enables one more
or the other? In other words, if we expressed this stmmac specific thing
in vendor-agnostic terminology that we already understand, would that work?

The ability of a single MAC to register 2 PHCs might be useful for TSN
switches as well. Long story short, sometimes those expose a free
running clock (uncorrectable in offset and frequency), as well as a
correctable one, and they give the option for PTP hardware timestamps to
sample one clock or the other. TSN offloads (tc-taprio, tc-gate etc)
always use the correctable clock, and 802.1AS / gPTP has the option to
use the free running clock. I'm not interested in this personally, but
there were some talks about the value of doing this some time ago, and I
thought it would be worth mentioning it in this context, as something
else that could benefit from a more generic UAPI.

> > Is it plausible that over time, when PTP timestamping matures and,
> > for example, MDIO devices get support for PTP_SYS_OFFSET_EXTENDED
> > (an attempt was here: https://lkml.org/lkml/2019/8/16/638), the
> > relationship between PTP clock qualities changes, and so does the
> > preference change?
> 
> I'm not exactly familiar with PTP_SYS_OFFSET_EXTENDED, but it looks a
> bit similar in purpose to the above-mentionned use-case.

Nope, not similar at all.
  

On Sun, 2 Apr 2023 20:12:49 +0300
Vladimir Oltean <vladimir.oltean@nxp.com> wrote:

> On Thu, Mar 30, 2023 at 02:38:24PM +0200, Köry Maincent wrote:
> > Hello Max,
> > 
> > On Fri, 17 Mar 2023 13:43:34 -0600
> > Max Georgiev <glipus@gmail.com> wrote:
> >   
> > > Jakub,
> > > 
> > > I started working on a patch introducing NDO functions for hw
> > > timestamping, but unfortunately put it on hold.
> > > Let me finish it and send it out for review.  
> > 
> > What is your timeline for it? Do you think of sending it in the followings
> > weeks, months, years? If you don't have much time ask for help, I am not
> > really a PTP core expert but I would gladly work with you on this.  
> 
> Köry, I believe you can start looking at that PHY driver whitelist
> (for changing the default timestamping layer) in parallel with Maxim's
> ndo_hwtstamp_set() effort, since they shouldn't depend on each other?

Yes, that's true. I will also update the change from ioctl to netlink to handle
the PTP layer selection.

Köry