Re: [PATCH RFC 2/2] net: dsa: bcm_sf2: implement HW bridging operations
From: Guenter Roeck <linux@roeck-us.net>
Date: 2015-02-19 17:46:45
On Thu, Feb 19, 2015 at 09:27:23AM -0800, Florian Fainelli wrote:
On 18/02/15 21:59, Guenter Roeck wrote:quoted
On Wed, Feb 18, 2015 at 06:48:19PM -0800, Florian Fainelli wrote:quoted
On 17/02/15 11:26, Florian Fainelli wrote:quoted
Update the Broadcom Starfighter 2 switch driver to implement the join/leave/stp_update callbacks required for basic hardware bridging support. There is not much to be done at the driver level but translating the STP state from Linux to their HW values. Joining a bridge means that the joining port and the other port members need to be in the same VLAN membership as the CPU, while leaving the bridge puts the port back into a separate VLAN membership with only the CPU.I found a couple additional issues while testing: - manipulating UP/DOWN state of interfaces that are part of a bridge would not restore their bridge membership - removing an interface from a bridge and bringing it back up would leave it in blocked stateIs this a problem with your implementation for sf2 or a generic problem with the first patch, such as some missing state transitions ?This is more of a side effect of having HW (an Ethernet switch) that can really block a given port, based on last night's discussion with Roopa, we can either fix this at the DSA level (in our case) or better fix this at the bridge layer, I will propose a fix for this shortly.quoted
For sf2, you might have to set the port state as well as the bridge association in the port_setup function. That is of course just a wild guess.Right, that's what I ended up doing. Thanks!
Great. Another question: How do you handle flushing the forwarding database ? My current code for mv88e6352 flushes the forwarding database for a bridge group if the port association for that group changes (whenever a port joins or leaves a group, or whenever the state of a port in a group changes). There is, however, another situation where the forwarding database may have to be flushed - essentially on each topology change. How do you handle this situation ? Is it a real problem or do I just imagine that it is ? Thanks, Guenter