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

Machnikowski, Maciej maciej.machnikowski@intel.com writes:

...

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

Maciej Machnikowski maciej.machnikowski@intel.com writes:

...

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

Signed-off-by: Maciej Machnikowski maciej.machnikowski@intel.com

...

...

...

+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

...

•                                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,

...

• 	 u32 *src_idx, struct netlink_ext_ack *extack);
  

+IFLA_EEC_SRC_IDX - optional attribute returning the index of the

reference

...

•    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.