lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 19 Feb 2019 11:37:58 -0800
From:   Florian Fainelli <>
To:     Russell King - ARM Linux admin <>,
        Vivien Didelot <>
Cc:     Andrew Lunn <>,
        Heiner Kallweit <>,
        "David S. Miller" <>,
Subject: Re: [PATCH net-next v2 2/3] net: dsa: mv88e6xxx: add support for
 bridge flags

On 2/19/19 11:10 AM, Russell King - ARM Linux admin wrote:
> On Tue, Feb 19, 2019 at 02:04:44PM -0500, Vivien Didelot wrote:
>> Hi Russell,
>> On Tue, 19 Feb 2019 18:08:11 +0000, Russell King - ARM Linux admin <> wrote:
>>> Having these as separate functions means that we would then need
>>> additional complexity in mv88e6xxx to store the per-port flooding state,
>>> so we can do this:
>>>         reg &= ~MV88E6352_PORT_CTL0_EGRESS_FLOODS_MASK;
>>>         if (unicast && multicast)
>>>                 reg |= MV88E6352_PORT_CTL0_EGRESS_FLOODS_ALL_UNKNOWN_DA;
>>>         else if (unicast)
>>>                 reg |= MV88E6352_PORT_CTL0_EGRESS_FLOODS_NO_UNKNOWN_MC_DA;
>>>         else if (multicast)
>>>                 reg |= MV88E6352_PORT_CTL0_EGRESS_FLOODS_NO_UNKNOWN_UC_DA;
>>>         else
>>>                 reg |= MV88E6352_PORT_CTL0_EGRESS_FLOODS_NO_UNKNOWN_DA;
>>> for some of the switches.  It looks to me like mv88e6xxx would prefer
>>> having at least both the unicast and multicast flags together.
>>> Even without that, it means more code in mv88e6xxx to wrap each of
>>> these calls between the DSA ops and the chip specific ops...
>> True, let's stick with ops->port_egress_flood(ds, port, bool uc, bool mc).
>> I do not think that it is necessary to add support for BR_BCAST_FLOOD yet,
>> we can extend this routine later if we need to.
>> Your dsa_port_bridge_flags() core function can notify the understood
>> features. This will allow us to scope the support of the bridge flags in
>> the core, and preventing the drivers to do that themselves.
> So, if we have ops->port_egress_flood, then we tell bridge that
> we support BR_FLOOD | BR_MCAST_FLOOD, irrespective of whether the
> bridge actually supports both?

I have a patch series which removes the need for BRIDGE_FLAGS_SUPPORT
and requires you to implement an attribute setter for PRE_BRIDGE_FLAGS,
there, you can map that to the same DSA switch operations and check the
flags and deny one or both that the driver does not support.

Should I re-send it and you submit on top, or the other way around?
Either way is fine, just tell me.

Powered by blists - more mailing lists