On 2018-12-23 2:57 p.m., Andrew Lunn wrote:
> On Sun, Dec 23, 2018 at 01:29:42PM -0600, Robert Hancock wrote:
>> On 2018-12-23 5:23 a.m., Andrew Lunn wrote:
>>> On Sat, Dec 22, 2018 at 08:29:08PM -0600, Robert Hancock wrote:
>>>> 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.
>>>
>>>> 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: hanc...@sedsystems.ca
