Andrew Lunn [off-list ref] writes:

quoted

+enum rtnl_link_down_reason_major {
+	RTNL_LDR_OTHER,

Does 'other' make any sense? Seem better to just not report anything
at all, or add a comment that more reasons should be added at the end
to reflect whatever the hardware or software can determine.

You still have the minor code to give you some information.

quoted

+	RTNL_LDR_NO_CABLE,
+	RTNL_LDR_UNSUPPORTED_CABLE,
+	RTNL_LDR_AUTONEG_FAILURE,
+	RTNL_LDR_NO_LINK_PARTNER,
+	RTNL_LDR_LINK_TRAINING_FAILURE,
+	RTNL_LDR_LOGICAL_MISMATCH,
+	RTNL_LDR_REMOTE_FAULT,
+	RTNL_LDR_BAD_SIGNAL_INTEGRITY,
+	RTNL_LDR_CALIBRATION_FAILURE,
+	RTNL_LDR_POWER_BUDGET_EXCEEDED,
+};

What about SFP cage empty?, i.e. no SFP, SFP+ module in the cage?  An

No cable? Maybe the name needs to change...

SFP can also report LOS. That does not appear to be any of the above.
Or that the core SFP code has been unable to read the EEPROM? We have

My assumption was that cable with unreadable EEPROM is simply a bad
cable. Does the admin actually care which particular part of the cable
is at fault?

people reporting this problem at the moment. We also have that the
SERDES has not yet obtained sync to its peer, which you know from
phylink_mac_change. That probably means the peer is using a different
bit rate.

We can add this.

I think it would be good if you handle the general case errors which
phylib and phylink can report, as well as the proprietary cases your
driver can report. We don't want this to be a Mellanox only API.

Sure, I'll take a look at that. I didn't need to deal with PHY so far,
so I need to figure out what's what.