Re: [PATCH v3 net-next 6/6] docs: net: Add description of SyncE interfaces

Machnikowski, Maciej [off-list ref] writes:

quoted

-----Original Message-----
From: Petr Machata <petrm@nvidia.com>
Sent: Thursday, November 11, 2021 1:43 PM
To: Machnikowski, Maciej <redacted>
Subject: Re: [PATCH v3 net-next 6/6] docs: net: Add description of SyncE
interfaces


Maciej Machnikowski [off-list ref] writes:

quoted

Add Documentation/networking/synce.rst describing new RTNL messages
and respective NDO ops supporting SyncE (Synchronous Ethernet).

Signed-off-by: Maciej Machnikowski <redacted>
---

...

quoted

quoted

+RTM_GETEECSTATE
+----------------
+Reads the state of the EEC or equivalent physical clock synchronizer.
+This message returns the following attributes:
+IFLA_EEC_STATE - current state of the EEC or equivalent clock generator.
+		 The states returned in this attribute are aligned to the
+		 ITU-T G.781 and are:
+		  IF_EEC_STATE_INVALID - state is not valid
+		  IF_EEC_STATE_FREERUN - clock is free-running
+		  IF_EEC_STATE_LOCKED - clock is locked to the reference,
+		                        but the holdover memory is not valid
+		  IF_EEC_STATE_LOCKED_HO_ACQ - clock is locked to the

reference

quoted

+		                               and holdover memory is valid
+		  IF_EEC_STATE_HOLDOVER - clock is in holdover mode
+State is read from the netdev calling the:
+int (*ndo_get_eec_state)(struct net_device *dev, enum if_eec_state

*state,

quoted

+			 u32 *src_idx, struct netlink_ext_ack *extack);
+
+IFLA_EEC_SRC_IDX - optional attribute returning the index of the

reference

quoted

+		   that is used for the current IFLA_EEC_STATE, i.e.,
+		   the index of the pin that the EEC is locked to.
+
+Will be returned only if the ndo_get_eec_src is implemented.
\ No newline at end of file

Just to be clear, I have much the same objections to this UAPI as I had
to v2:

- RTM_GETEECSTATE will become obsolete as soon as DPLL object is added.

Yes for more complex devices and no for simple ones

If we have an interface suitable for more complex netdevices, the
simpler ones can use it as well. Should in fact. There should not be two
interfaces for the same thing. For reasons of maintenance,
documentation, tool support, user experience.