linux-stable.git/include/net/dsa.h, branch v6.0.2

net: dsa: tag_ksz: add tag handling for Microchip LAN937x

2022-07-02T15:34:05+00:00

The Microchip LAN937X switches have a tagging protocol which is
very similar to KSZ tagging. So that the implementation is added to
tag_ksz.c and reused common APIs

Signed-off-by: Prasanna Vengateshan 
Signed-off-by: Arun Ramadoss 
Reviewed-by: Vladimir Oltean 
Reviewed-by: Florian Fainelli 
Signed-off-by: David S. Miller

net: dsa: add get_pause_stats support

2022-06-30T03:17:11+00:00

Add support for pause stats

Signed-off-by: Oleksij Rempel 
Reviewed-by: Vladimir Oltean 
Reviewed-by: Florian Fainelli 
Signed-off-by: Jakub Kicinski

net: dsa: add Renesas RZ/N1 switch tag driver

2022-06-27T10:37:55+00:00

The switch that is present on the Renesas RZ/N1 SoC uses a specific
VLAN value followed by 6 bytes which contains forwarding configuration.

Signed-off-by: Clément Léger 
Reviewed-by: Vladimir Oltean 
Reviewed-by: Florian Fainelli 
Signed-off-by: David S. Miller

net: dsa: add support for ethtool get_rmon_stats()

2022-06-27T10:37:55+00:00

Add support to allow dsa drivers to specify the .get_rmon_stats()
operation.

Signed-off-by: Clément Léger 
Reviewed-by: Vladimir Oltean 
Reviewed-by: Florian Fainelli 
Signed-off-by: David S. Miller

net: dsa: remove port argument from ->change_tag_protocol()

2022-05-12T23:38:55+00:00

DSA has not supported (and probably will not support in the future
either) independent tagging protocols per CPU port.

Different switch drivers have different requirements, some may need to
replicate some settings for each CPU port, some may need to apply some
settings on a single CPU port, while some may have to configure some
global settings and then some per-CPU-port settings.

In any case, the current model where DSA calls ->change_tag_protocol for
each CPU port turns out to be impractical for drivers where there are
global things to be done. For example, felix calls dsa_tag_8021q_register(),
which makes no sense per CPU port, so it suppresses the second call.

Let drivers deal with replication towards all CPU ports, and remove the
CPU port argument from the function prototype.

Signed-off-by: Vladimir Oltean 
Acked-by: Luiz Angelo Daros de Luca 
Signed-off-by: Jakub Kicinski

net: dsa: felix: manage host flooding using a specific driver callback

2022-05-12T23:38:55+00:00

At the time - commit 7569459a52c9 ("net: dsa: manage flooding on the CPU
ports") - not introducing a dedicated switch callback for host flooding
made sense, because for the only user, the felix driver, there was
nothing different to do for the CPU port than set the flood flags on the
CPU port just like on any other bridge port.

There are 2 reasons why this approach is not good enough, however.

(1) Other drivers, like sja1105, support configuring flooding as a
    function of {ingress port, egress port}, whereas the DSA
    ->port_bridge_flags() function only operates on an egress port.
    So with that driver we'd have useless host flooding from user ports
    which don't need it.

(2) Even with the felix driver, support for multiple CPU ports makes it
    difficult to piggyback on ->port_bridge_flags(). The way in which
    the felix driver is going to support host-filtered addresses with
    multiple CPU ports is that it will direct these addresses towards
    both CPU ports (in a sort of multicast fashion), then restrict the
    forwarding to only one of the two using the forwarding masks.
    Consequently, flooding will also be enabled towards both CPU ports.
    However, ->port_bridge_flags() gets passed the index of a single CPU
    port, and that leaves the flood settings out of sync between the 2
    CPU ports.

This is to say, it's better to have a specific driver method for host
flooding, which takes the user port as argument. This solves problem (1)
by allowing the driver to do different things for different user ports,
and problem (2) by abstracting the operation and letting the driver do
whatever, rather than explicitly making the DSA core point to the CPU
port it thinks needs to be touched.

This new method also creates a problem, which is that cross-chip setups
are not handled. However I don't have hardware right now where I can
test what is the proper thing to do, and there isn't hardware compatible
with multi-switch trees that supports host flooding. So it remains a
problem to be tackled in the future.

Signed-off-by: Vladimir Oltean 
Signed-off-by: Jakub Kicinski

net: dsa: introduce the dsa_cpu_ports() helper

2022-05-12T23:38:54+00:00

Similar to dsa_user_ports() which retrieves a port mask of all user
ports, introduce dsa_cpu_ports() which retrieves the mask of all CPU
ports of a switch.

Signed-off-by: Vladimir Oltean 
Signed-off-by: Jakub Kicinski

net: dsa: delete dsa_port_walk_{fdbs,mdbs}

2022-05-07T04:00:12+00:00

All the users of these functions are gone, delete them before they gain
new ones.

Signed-off-by: Vladimir Oltean 
Signed-off-by: Jakub Kicinski

net: dsa: pass extack to dsa_switch_ops :: port_mirror_add()

2022-03-18T00:42:47+00:00

Drivers might have error messages to propagate to user space, most
common being that they support a single mirror port.

Propagate the netlink extack so that they can inform user space in a
verbal way of their limitations.

Signed-off-by: Vladimir Oltean 
Signed-off-by: Jakub Kicinski

net: dsa: Handle MST state changes

2022-03-17T23:49:59+00:00

Add the usual trampoline functionality from the generic DSA layer down
to the drivers for MST state changes.

When a state changes to disabled/blocking/listening, make sure to fast
age any dynamic entries in the affected VLANs (those controlled by the
MSTI in question).

Signed-off-by: Tobias Waldekranz 
Reviewed-by: Vladimir Oltean 
Signed-off-by: Jakub Kicinski