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 > <li...@armlinux.org.uk> 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? -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
