On 2018-12-23 2:57 p.m., Andrew Lunn wrote:

On Sun, Dec 23, 2018 at 01:29:42PM -0600, Robert Hancock wrote:

quoted

On 2018-12-23 5:23 a.m., Andrew Lunn wrote:

quoted

On Sat, Dec 22, 2018 at 08:29:08PM -0600, Robert Hancock wrote:

quoted

I have a device using a KSZ9897 switch
(CONFIG_MICROCHIP_KSZ_SPI_DRIVER=y) using a 4.19.9 kernel, where I am
trying to enable a bridge on some of the ports using systemd-networkd.

Hi Robert

I don't think many of use use such a setup, so we probably have not
noticed this.

quoted

However, it seems to be getting an error when it tries to configure the
ports to be part of the bridge. systemd-networkd complains with:

lan1: Set link
lan1: Could not join netdev: Operation not supported
lan1: Failed

and the kernel complains:

lan: bridge flag offload is not supported 4(lan1)

That message is coming from br_switchdev_set_port_flag in
net/bridge/br_switchdev.c. Adding some more output to that statement
tells me:

lan: bridge flag offload is not supported, flags 18656 mask 64 support
0, 4(lan1)

which appears to mean something is trying to enable BR_BCAST_FLOOD,
BR_MCAST_FLOOD, BR_PROMISC, BR_FLOOD, BR_LEARNING on the port, but it is
failing to enable BR_FLOOD because brport_flags_support is 0. I am just
using the default bridge settings in systemd-networkd, so that is
nothing that I am specifying explicitly.

I think this is a systemd problem. It should first query what flags
are supported. See

dc0ecabd6231 ("net: switchdev: Add support for querying supported bridge flags by hardware")

And then only try to turn on flags which are supported.  If it tries
to turn on flags which are not supported, an error is the correct
thing to do.

I may be missing some context about how the switchdev/DSA code works, but
are those flags actually unsupported, or just unsupported in hardware
offload? Userspace doesn't know or care about the hardware offload
capability of the switch, it's just trying to set standard flags on the
bridge.

Hi Robert

We really need Arkadi Sharshevsky to comment on this.

FYI, changing the code in question to return 0 instead of -EOPNOTSUPP in
the missing brport_flags_support flag case allows systemd-networkd to
initialize the port successfully. We have some other issues in our
hardware setup that prevent me from testing that fully at the moment,
but I will likely submit that as a patch shortly unless I hear of a
better solution..

-- 
Robert Hancock
Senior Software Developer
SED Systems
Email: hancock@sedsystems.ca