Merge branch 'mlxsw-Removing-dependency-of-mlxsw-on-GRE'

Merge branch 'mlxsw-Removing-dependency-of-mlxsw-on-GRE'

Ido Schimmel says:

====================
mlxsw: Removing dependency of mlxsw on GRE

Petr says:

mlxsw_spectrum supports offloading of a tc action mirred egress mirror
to a gretap or ip6gretap netdevice, which necessitates calls to
functions defined in ip_gre, ip6_gre and ip6_tunnel modules. Previously
this was enabled by introducing a hard dependency of MLXSW_SPECTRUM on
NET_IPGRE and IPV6_GRE. However the rest of mlxsw is careful about
picking which modules are absolutely required, and therefore the better
approach is to make mlxsw_spectrum tolerant of absence of one or both of
the GRE flavors.

One way this might be resolved is by keeping the code in mlxsw_spectrum
intact, and defining defaults for functions that mlxsw_spectrum depends
on. The downsides are that other modules end up littered with these
do-nothing defaults; that the driver ends up carrying quite a bit of
dead code; and that the driver ends up having to explicitly depend on
IPV6_TUNNEL to prevent configurations where mlxsw_spectrum is compiled
in and and ip6_tunnel is a module, something that it currently can treat
as an implementation detail of the IPV6_GRE dependency.

Alternatively, the driver should just bite the bullet and ifdef-out the
code that handles configurations that are not supported. Since that's
what we are doing for IPv6 dependency, let's do the same for the GRE
flavors.

Patch #1 introduces a wrapper function for determining the value of
ipv6.sysctl.multipath_hash_policy, which defaults to 0 on non-IPv6
builds. That function is then used from spectrum_router.c, instead of
the direct variable reference that was introduced there during the short
window when the Spectrum driver had a hard dependency on IPv6.

Patch #2 moves one function to keep together in one block all the
callbacks for handling (IPv4) gretap mirroring.

Patch #3 then introduces the ifdefs to hide the irrelevant code.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>