On Thu, Oct 19, 2017 at 2:07 AM, Yuval Mintz [off-list ref]
wrote:

quoted

quoted

+enum devlink_autoneg_protocol {
+     DEVLINK_AUTONEG_PROTOCOL_IEEE8023BY_BAM,
+     DEVLINK_AUTONEG_PROTOCOL_IEEE8023BY_CONSORTIUM,
+     DEVLINK_AUTONEG_PROTOCOL_IEEE8023BY,
+     DEVLINK_AUTONEG_PROTOCOL_BAM,           /* Broadcom
Autoneg Mode */
+     DEVLINK_AUTONEG_PROTOCOL_CONSORTIUM,    /*
Consortium Autoneg Mode */
+};

Wouldn't adding BAM as a 'generic' mode of operation be like adding
non-consortium speeds to ethtool API?
[I profess ignorance in this area; For all I know it can be a widely accepted
industry standard]

Yuval, I'm glad to get input from other NIC vendors.  

Other switch vendors ;)

The high-level goal of this effort is to allow users of various vendors' NICs to be
able to configure these types of NVRAM/permanent/default settings
using an inbox tool, rather than the collection of vendor-specific
tools that is the status quo.

In order to provide that functionality, it seems like the
vendor-specific parameters and also the vendor-specific settings of
common parameters both need to be supported in this manner.

Ideally there will be much overlap in both the set of parameters
available as well as the options for each parameter, but in the real
world, there will always be differences between vendors and even
between different devices (drivers) from the same vendor.  Despite
that reality, I think there is still great benefit in having a common
inbox tool that users can use for device configuration of this type.
It just means that not all drivers will support all parameters, nor
all options for each parameter that they do support.

I don't object the end-goal; I think my hesitation is due to the same
enum containing both generic and vendor-specific values mixed
together. I feel like we need some clear distinction between the two.

Thanks,
Steve