Make the driver ops-locked in order to allow ethtool operations to be
invoked without RTNL being held.

An ops-locked driver has most of its NDOs, all of its ethtool operations
and some net device notifications run with the netdev instance lock
held.

In the specific case of mlxsw, the driver is not using any functions
that acquire this lock nor functions that expect the lock to be held for
an ops-locked driver. Therefore, converting its NDOs to run with the
lock being held is trivial except for a small quirk which is handled in
patch #1.

The driver does not generate any net device notifications, so there is
no risk of nested notifications of the ops-locked types. For the
notifications that run under the instance lock, RTNL is also held, and
the driver does not acquire the instance lock itself, so no changes are
required in its notifier handling.

Ethtool operations can be invoked without RTNL except for two operations
that are annotated in patch #2.

Lastly, patch #3 converts the driver to be ops-locked.

A probe on rtnl_lock() shows it is no longer taken when dumping
statistics:

 # perf probe --add rtnl_lock

Before:

 # perf stat -e probe:rtnl_lock -- ethtool -S swp1 --all-groups
 [...]
                  1      probe:rtnl_lock

After:

 # perf stat -e probe:rtnl_lock -- ethtool -S swp1 --all-groups
 [...]
                  0      probe:rtnl_lock

No issues were reported after running a full regression with a debug
config that has lockdep enabled.

Ido Schimmel (3):
  mlxsw: Convert to async version of ndo_set_rx_mode
  mlxsw: ethtool: Prepare for RTNL-less ethtool operations
  mlxsw: Tell the core to use the netdev instance lock

 drivers/net/ethernet/mellanox/mlxsw/spectrum.c         | 8 ++++++--
 drivers/net/ethernet/mellanox/mlxsw/spectrum_ethtool.c | 2 ++
 2 files changed, 8 insertions(+), 2 deletions(-)

-- 
2.54.0