Message ID | 20230308135936.761794-4-kory.maincent@bootlin.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp354958wrd; Wed, 8 Mar 2023 06:12:56 -0800 (PST) X-Google-Smtp-Source: AK7set83471ks/TvGJLP5OEAuvlW0fTRmNKMLj4mW21grR/Bz+NIxPs8naoh7sKfJm9gvGUJhQOL X-Received: by 2002:a17:906:9c86:b0:914:4277:f3e1 with SMTP id fj6-20020a1709069c8600b009144277f3e1mr8256549ejc.53.1678284776154; Wed, 08 Mar 2023 06:12:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1678284776; cv=none; d=google.com; s=arc-20160816; b=G/FM9GpfMDuFoQAdmtPyf8YLGBFXqDa7Sxb33+Fmk3KDWl9FYyANnlDslU5Spx5Wpx iWv6TjVQlP8q7604XoxrMX1sRepMLnIyYqI0cpz+mXxls/HIwFpaxfsPasw2xP8aFUoD WLX008zU7f/SaAu/fNqXIS8MbAEaprczPWjbAmkl3NtEzvXewn2M7qXK80FWvgPa9UBm fozNOslwr9zuxOJUUwSecyIbtYpiBosvYLZy5/HhI2MbLSEIhdyJwGxLFqKws6aTiLNN owzdM43moLj0buBvhbYBVdjfpxRbDahatfdsWeaBJ8KiA1Q0qhWLau7/8/xbrIA6BlOx McKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=6lf6IjatvOcyoWSFI3/mxSXIMBx/zkHwZGUcOEydNR8=; b=Vp1LhH3dNjR1Bn8ZdJGD/8n5An9SJY9c+owwicGC4zrY4PupRU8mRnkhmcdFUKuwp0 DqfolW67w1LocVE0zXXu93Law0Li+JmfC7Pb6UQooEy1W86XA6ZbMTHpEa0JcVBkt4Yy bRPJEljNAsPTXl1GSvlyf4I+Ui3mwHs0+2x3BLhz1cVHuqdAipy33yyARV5KFNKaoUM0 4qnm+kiBk3WtPe8m6Wd+2MGU7GtgTfh5eN2d0rb6UUtQlPZ2RtRuijP+HkW4jC5BxGlW G5IuH5WHNaFg1rAZKVUWUrC/9wqXaX4xErQy/LhDuT2k73hdzFNUMaU0CO+wesDxqyhP DbzQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=AJF3cSBf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bootlin.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id mp28-20020a1709071b1c00b008e649198db8si21108384ejc.720.2023.03.08.06.12.32; Wed, 08 Mar 2023 06:12:56 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=AJF3cSBf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bootlin.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232067AbjCHOCa (ORCPT <rfc822;realc9580@gmail.com> + 99 others); Wed, 8 Mar 2023 09:02:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38200 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231946AbjCHOBV (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 8 Mar 2023 09:01:21 -0500 Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F1EEF3D09F; Wed, 8 Mar 2023 06:00:26 -0800 (PST) Received: (Authenticated sender: kory.maincent@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id 0CF0D1C0002; Wed, 8 Mar 2023 14:00:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1678284025; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6lf6IjatvOcyoWSFI3/mxSXIMBx/zkHwZGUcOEydNR8=; b=AJF3cSBf4TaQaO2LV/YVHEbq7u++t/Ey4WmwvhT2pIC5jTUuxrjqyyVCqiUIHi2XNzj3nE Ha5ukFCiiArhYR2cdlqftJ4ChfXdo/4saBayG0AYmqNlb5u1MTEsWLmMc96OlOV/iiPqB1 1O79SckAfDBmU/4arZd1aJBvn/tDuArCkTqhydNliZv5Vu6D3a079xm/rjiN+ZvdcILRCN qM8w0vvZ3TLaqS/HJPBl1/0bW4PC/OJRGVvcF3zvbAj4ggQFlsV/lRAE5k5gC/nB/dGlUU Vc0p8W1Xq9GE5hGxEUFwn9uW3Jo/uKMPGGB+OnPqzi6Wi7HCS0XtA1e8aYBiJA== From: =?utf-8?q?K=C3=B6ry_Maincent?= <kory.maincent@bootlin.com> To: Andrew Lunn <andrew@lunn.ch>, Florian Fainelli <f.fainelli@gmail.com>, Heiner Kallweit <hkallweit1@gmail.com>, netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-omap@vger.kernel.org Cc: Michael Walle <michael@walle.cc>, Maxime Chevallier <maxime.chevallier@bootlin.com>, Richard Cochran <richardcochran@gmail.com>, Kory Maincent <kory.maincent@bootlin.com>, thomas.petazzoni@bootlin.com, Russell King <linux@armlinux.org.uk>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Jonathan Corbet <corbet@lwn.net>, Jay Vosburgh <j.vosburgh@gmail.com>, Veaceslav Falico <vfalico@gmail.com>, Andy Gospodarek <andy@greyhouse.net>, Joakim Zhang <qiangqing.zhang@nxp.com>, Vladimir Oltean <vladimir.oltean@nxp.com>, Claudiu Manoil <claudiu.manoil@nxp.com>, Alexandre Belloni <alexandre.belloni@bootlin.com>, UNGLinuxDriver@microchip.com, Grygorii Strashko <grygorii.strashko@ti.com>, Minghao Chi <chi.minghao@zte.com.cn>, Guangbin Huang <huangguangbin2@huawei.com>, Jie Wang <wangjie125@huawei.com>, Oleksij Rempel <linux@rempel-privat.de>, Sean Anderson <sean.anderson@seco.com>, Alexandru Tachici <alexandru.tachici@analog.com>, "Gustavo A. R. Silva" <gustavoars@kernel.org>, Wolfram Sang <wsa+renesas@sang-engineering.com>, Alexander Lobakin <alexandr.lobakin@intel.com>, Marco Bonelli <marco@mebeim.net> Subject: [PATCH v3 3/5] net: Let the active time stamping layer be selectable. Date: Wed, 8 Mar 2023 14:59:27 +0100 Message-Id: <20230308135936.761794-4-kory.maincent@bootlin.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20230308135936.761794-1-kory.maincent@bootlin.com> References: <20230308135936.761794-1-kory.maincent@bootlin.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759809137639034595?= X-GMAIL-MSGID: =?utf-8?q?1759809137639034595?= |
Series |
net: Make MAC/PHY time stamping selectable
|
|
Commit Message
Köry Maincent
March 8, 2023, 1:59 p.m. UTC
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(-)
Comments
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
diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst index ca8e1182bc8e..4a1153dd4859 100644 --- a/Documentation/networking/ethtool-netlink.rst +++ b/Documentation/networking/ethtool-netlink.rst @@ -1789,4 +1789,5 @@ are netlink only. n/a ``ETHTOOL_MSG_MODULE_SET`` ``ETHTOOL_LIST_PTP`` n/a ``ETHTOOL_GET_PTP`` n/a + ``ETHTOOL_SET_PTP`` n/a =================================== ===================================== diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c index 8cff61dbc4b5..5e120452a358 100644 --- a/drivers/net/phy/phy_device.c +++ b/drivers/net/phy/phy_device.c @@ -34,6 +34,9 @@ #include <linux/string.h> #include <linux/uaccess.h> #include <linux/unistd.h> +#include <linux/of.h> +#include <uapi/linux/net_tstamp.h> + MODULE_DESCRIPTION("PHY library"); MODULE_AUTHOR("Andy Fleming"); @@ -1378,6 +1381,34 @@ int phy_sfp_probe(struct phy_device *phydev, } EXPORT_SYMBOL(phy_sfp_probe); +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; +} + /** * phy_attach_direct - attach a network device to a given PHY device pointer * @dev: network device to attach @@ -1451,6 +1482,8 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev, phydev->phy_link_change = phy_link_change; if (dev) { + of_set_timestamp(dev, phydev); + phydev->attached_dev = dev; dev->phydev = phydev; @@ -1762,6 +1795,7 @@ void phy_detach(struct phy_device *phydev) phy_suspend(phydev); if (dev) { + dev->selected_timestamping_layer = MAC_TIMESTAMPING; phydev->attached_dev->phydev = NULL; phydev->attached_dev = NULL; } 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; + struct list_head net_notifier_list; #if IS_ENABLED(CONFIG_MACSEC) diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h index 56cf24388290..d3a41b6e9eb0 100644 --- a/include/uapi/linux/ethtool.h +++ b/include/uapi/linux/ethtool.h @@ -1631,6 +1631,7 @@ enum ethtool_fec_config_bits { #define ETHTOOL_SFECPARAM 0x00000051 /* Set FEC settings */ #define ETHTOOL_LIST_PTP 0x00000052 /* List PTP providers */ #define ETHTOOL_GET_PTP 0x00000053 /* Get current PTP provider */ +#define ETHTOOL_SET_PTP 0x00000054 /* Set PTP provider */ /* compatibility with older code */ #define SPARC_ETH_GSET ETHTOOL_GSET diff --git a/net/core/dev_ioctl.c b/net/core/dev_ioctl.c index 7674bb9f3076..a75cff331495 100644 --- a/net/core/dev_ioctl.c +++ b/net/core/dev_ioctl.c @@ -262,6 +262,42 @@ static int dev_eth_ioctl(struct net_device *dev, return err; } +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); + } + break; + } + + return err; +} + static int dev_siocbond(struct net_device *dev, struct ifreq *ifr, unsigned int cmd) { @@ -397,6 +433,9 @@ static int dev_ifsioc(struct net *net, struct ifreq *ifr, void __user *data, return err; fallthrough; + case SIOCGHWTSTAMP: + return dev_hwtstamp_ioctl(dev, ifr, cmd); + /* * Unknown or private ioctl */ @@ -407,9 +446,7 @@ static int dev_ifsioc(struct net *net, struct ifreq *ifr, void __user *data, if (cmd == SIOCGMIIPHY || cmd == SIOCGMIIREG || - cmd == SIOCSMIIREG || - cmd == SIOCSHWTSTAMP || - cmd == SIOCGHWTSTAMP) { + cmd == SIOCSMIIREG) { err = dev_eth_ioctl(dev, ifr, cmd); } else if (cmd == SIOCBONDENSLAVE || cmd == SIOCBONDRELEASE || diff --git a/net/core/timestamping.c b/net/core/timestamping.c index 04840697fe79..31c3142787b7 100644 --- a/net/core/timestamping.c +++ b/net/core/timestamping.c @@ -28,6 +28,9 @@ void skb_clone_tx_timestamp(struct sk_buff *skb) if (!skb->sk) return; + if (skb->dev->selected_timestamping_layer != PHY_TIMESTAMPING) + return; + type = classify(skb); if (type == PTP_CLASS_NONE) return; @@ -50,6 +53,9 @@ bool skb_defer_rx_timestamp(struct sk_buff *skb) if (!skb->dev || !skb->dev->phydev || !skb->dev->phydev->mii_ts) return false; + if (skb->dev->selected_timestamping_layer != PHY_TIMESTAMPING) + return false; + if (skb_headroom(skb) < ETH_HLEN) return false; 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; + } info->so_timestamping = SOF_TIMESTAMPING_RX_SOFTWARE | SOF_TIMESTAMPING_SOFTWARE; diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c index d8a0a5d991e0..85a074bef17d 100644 --- a/net/ethtool/ioctl.c +++ b/net/ethtool/ioctl.c @@ -2343,17 +2343,8 @@ static int ethtool_get_ptp(struct net_device *dev, void __user *useraddr) { struct ethtool_value edata = { .cmd = ETHTOOL_GET_PTP, - .data = 0, + .data = dev->selected_timestamping_layer, }; - struct phy_device *phydev = dev->phydev; - const struct ethtool_ops *ops = dev->ethtool_ops; - - if (phy_has_tsinfo(phydev)) - edata.data = PHY_TIMESTAMPING; - else if (ops->get_ts_info) - edata.data = MAC_TIMESTAMPING; - else - return -EOPNOTSUPP; if (copy_to_user(useraddr, &edata, sizeof(edata))) return -EFAULT; @@ -2361,6 +2352,33 @@ static int ethtool_get_ptp(struct net_device *dev, void __user *useraddr) return 0; } +static int ethtool_set_ptp(struct net_device *dev, void __user *useraddr) +{ + struct ethtool_value edata; + enum timestamping_layer flavor; + + if (copy_from_user(&edata, useraddr, sizeof(edata))) + return -EFAULT; + + flavor = edata.data; + + if (!dev->phydev) + return 0; + + if (dev->selected_timestamping_layer != flavor) { + const struct net_device_ops *ops = dev->netdev_ops; + struct ifreq ifr = {0}; + + /* Disable time stamping in the current layer. */ + if (netif_device_present(dev) && ops->ndo_eth_ioctl) + ops->ndo_eth_ioctl(dev, &ifr, SIOCSHWTSTAMP); + + dev->selected_timestamping_layer = flavor; + } + + return 0; +} + int ethtool_get_module_info_call(struct net_device *dev, struct ethtool_modinfo *modinfo) { @@ -3047,6 +3065,9 @@ __dev_ethtool(struct net *net, struct ifreq *ifr, void __user *useraddr, case ETHTOOL_GET_PTP: rc = ethtool_get_ptp(dev, useraddr); break; + case ETHTOOL_SET_PTP: + rc = ethtool_set_ptp(dev, useraddr); + break; default: rc = -EOPNOTSUPP; }