[net-next,v18,00/10] net: Make timestamping selectable

Message

Kory Maincent Oct. 23, 2024, 3:49 p.m. UTC

Up until now, there was no way to let the user select the hardware
PTP provider at which time stamping occurs. The stack assumed that PHY time
stamping is always preferred, but some MAC/PHY combinations were buggy.

This series updates the default MAC/PHY default timestamping and aims to
allow the user to select the desired hwtstamp provider administratively.

The series is based on the following netlink spec and documentation patches:
https://lore.kernel.org/netdev/[e-mail]/
https://lore.kernel.org/netdev/[e-mail]/

Changes in v18:
- Few changes in the tsconfig-set ethtool command.
- Add tsconfig-set-reply ethtool netlink socket.
- Add missing netlink tsconfig documentation
- Link to v17: https://lore.kernel.org/r/[e-mail]

Changes in v17:
- Fix a documentation nit.
- Add a missing kernel_ethtool_tsinfo update from a new MAC driver.
- Link to v16: https://lore.kernel.org/r/[e-mail]

Changes in v16:
- Add a new patch to separate tsinfo into a new tsconfig command to get
  and set the hwtstamp config.
- Used call_rcu() instead of synchronize_rcu() to free the hwtstamp_provider
- Moved net core changes of patch 12 directly to patch 8.
- Link to v15: https://lore.kernel.org/r/[e-mail]

Changes in v15:
- Fix uninitialized ethtool_ts_info structure.
- Link to v14: https://lore.kernel.org/r/[e-mail]

Changes in v14:
- Add back an EXPORT_SYMBOL() missing.
- Link to v13: https://lore.kernel.org/r/[e-mail]

Changes in v13:
- Add PTP builtin code to fix build errors when building PTP as a module.
- Fix error spotted by smatch and sparse.
- Link to v12: https://lore.kernel.org/r/[e-mail]

Changes in v12:
- Add missing return description in the kdoc.
- Fix few nit.
- Link to v11: https://lore.kernel.org/r/[e-mail]

Changes in v11:
- Add netlink examples.
- Remove a change of my out of tree marvell_ptp patch in the patch series.
- Remove useless extern.
- Link to v10: https://lore.kernel.org/r/[e-mail]

Changes in v10:
- Move declarations to net/core/dev.h instead of netdevice.h
- Add netlink documentation.
- Add ETHTOOL_A_TSINFO_GHWTSTAMP netlink attributes instead of a bit in
  ETHTOOL_A_TSINFO_TIMESTAMPING bitset.
- Send "Move from simple ida to xarray" patch standalone.
- Add tsinfo ntf command.
- Add rcu_lock protection mechanism to avoid memory leak.
- Fixed doc and kdoc issue.
- Link to v9: https://lore.kernel.org/r/[e-mail]

Changes in v9:
- Remove the RFC prefix.
- Correct few NIT fixes.
- Link to v8: https://lore.kernel.org/r/[e-mail]

Changes in v8:
- Drop the 6 first patch as they are now merged.
- Change the full implementation to not be based on the hwtstamp layer
  (MAC/PHY) but on the hwtstamp provider which mean a ptp clock and a
  phc qualifier.
- Made some patch to prepare the new implementation.
- Expand netlink tsinfo instead of a new ts command for new hwtstamp
  configuration uAPI and for dumping tsinfo of specific hwtstamp provider.
- Link to v7: https://lore.kernel.org/r/[e-mail]

Changes in v7:
- Fix a temporary build error.
- Link to v6: https://lore.kernel.org/r/[e-mail]

Changes in v6:
- Few fixes from the reviews.
- Replace the allowlist to default_timestamp flag to know which phy is
  using old API behavior.
- Rename the timestamping layer enum values.
- Move to a simple enum instead of the mix between enum and bitfield.
- Update ts_info and ts-set in software timestamping case.

Changes in v5:
- Update to ndo_hwstamp_get/set. This bring several new patches.
- Add few patches to make the glue.
- Convert macb to ndo_hwstamp_get/set.
- Add netlink specs description of new ethtool commands.
- Removed netdev notifier.
- Split the patches that expose the timestamping to userspace to separate
  the core and ethtool development.
- Add description of software timestamping.
- Convert PHYs hwtstamp callback to use kernel_hwtstamp_config.

Changes in v4:
- Move on to ethtool netlink instead of ioctl.
- Add a netdev notifier to allow packet trapping by the MAC in case of PHY
  time stamping.
- Add a PHY whitelist to not break the old PHY default time-stamping
  preference API.

Changes in v3:
- Expose the PTP choice to ethtool instead of sysfs.
  You can test it with the ethtool source on branch feature_ptp of:
  https://github.com/kmaincent/ethtool
- Added a devicetree binding to select the preferred timestamp.

Changes in v2:
- Move selected_timestamping_layer variable of the concerned patch.
- Use sysfs_streq instead of strmcmp.
- Use the PHY timestamp only if available.

Signed-off-by: Kory Maincent <[e-mail]>
---
Kory Maincent (10):
      net: Make dev_get_hwtstamp_phylib accessible
      net: Make net_hwtstamp_validate accessible
      ptp: Add phc source and helpers to register specific PTP clock or get information
      net: Add the possibility to support a selected hwtstamp in netdevice
      net: netdevsim: ptp_mock: Convert to netdev_ptp_clock_register
      net: macb: Convert to netdev_ptp_clock_register
      net: ptp: Move ptp_clock_index() to builtin symbol
      net: ethtool: tsinfo: Add support for reading tsinfo for a specific hwtstamp provider
      net: ethtool: Add support for tsconfig command to get/set hwtstamp config
      netlink: specs: Enhance tsinfo netlink attributes and add a tsconfig set command

 Documentation/netlink/specs/ethtool.yaml     |  70 +++++
 Documentation/networking/ethtool-netlink.rst |  83 +++++-
 Documentation/networking/timestamping.rst    |  38 ++-
 drivers/net/ethernet/cadence/macb_ptp.c      |   2 +-
 drivers/net/netdevsim/netdev.c               |  19 +-
 drivers/net/phy/phy_device.c                 |  11 +
 drivers/ptp/Makefile                         |   5 +
 drivers/ptp/ptp_clock.c                      |  39 ++-
 drivers/ptp/ptp_clock_consumer.c             | 182 ++++++++++++
 drivers/ptp/ptp_mock.c                       |   4 +-
 drivers/ptp/ptp_private.h                    |   7 +
 include/linux/ethtool.h                      |   4 +
 include/linux/net_tstamp.h                   |  18 ++
 include/linux/netdevice.h                    |   5 +
 include/linux/ptp_clock_kernel.h             | 188 +++++++++++++
 include/linux/ptp_mock.h                     |   4 +-
 include/uapi/linux/ethtool_netlink.h         |  30 +-
 include/uapi/linux/net_tstamp.h              |  11 +
 net/core/dev.h                               |   3 +
 net/core/dev_ioctl.c                         |  49 +++-
 net/core/timestamping.c                      |  50 +++-
 net/ethtool/Makefile                         |   2 +-
 net/ethtool/common.c                         |  33 +++
 net/ethtool/common.h                         |   3 +
 net/ethtool/netlink.c                        |  26 +-
 net/ethtool/netlink.h                        |   8 +-
 net/ethtool/ts.h                             |  52 ++++
 net/ethtool/tsconfig.c                       | 406 +++++++++++++++++++++++++++
 net/ethtool/tsinfo.c                         | 239 +++++++++++++++-
 29 files changed, 1532 insertions(+), 59 deletions(-)
---
base-commit: 76a212bdb59ed3da084203356c0df41c4cabd428
change-id: 20231011-feature_ptp_netnext-3f278578e84b

Best regards,

Comments

Vladimir Oltean Oct. 24, 2024, 2:04 p.m. UTC | #1

On Wed, Oct 23, 2024 at 05:49:10PM +0200, Kory Maincent wrote:
> The series is based on the following netlink spec and documentation patches:
> https://lore.kernel.org/netdev/[e-mail]/
> https://lore.kernel.org/netdev/[e-mail]/

No point in posting a non-RFC patch revision if it conflicts with unmerged
dependencies. Since it doesn't apply cleanly, the NIPA CI won't run on it
and it won't be a candidate for merging due to that. But, if you post as
RFC PATCH v18 instead, you make it crystal clear for the reviewers involved
that you only request feedback.

Kory Maincent Oct. 24, 2024, 2:22 p.m. UTC | #2

On Thu, 24 Oct 2024 17:04:22 +0300
Vladimir Oltean <[e-mail]> wrote:

> On Wed, Oct 23, 2024 at 05:49:10PM +0200, Kory Maincent wrote:
> > The series is based on the following netlink spec and documentation patches:
> > https://lore.kernel.org/netdev/[e-mail]/
> > https://lore.kernel.org/netdev/[e-mail]/
> >  
> 
> No point in posting a non-RFC patch revision if it conflicts with unmerged
> dependencies. Since it doesn't apply cleanly, the NIPA CI won't run on it
> and it won't be a candidate for merging due to that. But, if you post as
> RFC PATCH v18 instead, you make it crystal clear for the reviewers involved
> that you only request feedback.

I naively thought net maintainers could rerun the CI after these patch get
merged. I will need to repost a v19 later then.
Sorry for the noise.

Regards,