Florian Fainelli <f.fainelli@xxxxxxxxx> writes: > You seem to have approached the bridge changes a little differently from > this series: > > https://lists.linux-foundation.org/pipermail/bridge/2016-November/010112.html It pretty much extends the patchset to also send the notifications for the CPU port. I missed this e-mail yesterday and now I see you already found out for yourself how it behaves. > Both have the same intent that by targeting the bridge device itself, > you can propagate that through switchdev to the switch drivers, and in > turn create configurations where for instance, you have: > > - CPU/management port present in specific VLANs that is a subset or > superset of the VLANs configured on front-panel ports > - CPU/management port tagged/untagged in specific VLANs which can be a > different setting from the front-panel ports > > One problem we have in DSA at the moment is that we always add the CPU > port to the VLANs configured to the front-panel port but we do this with > the same attributes as the front panel ports! For instance, if you add > Port 0 to VLAN1 untagged, the the CPU port also gets added to that > VLAN1, also untagged. As long as there is just one VLAN untagged, this > is not much of a problem. Now do this with another VLAN or another port, > and the CPU can no longer differentiate the traffic from which VLAN it > is coming from, no bueno. Yep, with this patchset you should be able to use the CPU port notifications to configure things exactly. > bridge vlan add vid 2 dev port0 pvid untagged > -> port0 (e.g: switch port 0) gets programmed > -> CPU port gets programmed > bridge vlan add vid 2 dev br0 self > -> CPU port gets programmed > bridge vlan add vid 2 dev port0 > -> port0 (switch port 0) gets programmed > > Are these use cases possible with your series? It seems to me like it is > if we drop the netif_is_bridge_master() checks and resolve orig_dev as > being a hint for the CPU/management port. Yeah, that's how it behaves. If you accept the events where netif_is_bridge_master(orig_dev), you can tell the CPU port-related events from the rest by BRIDGE_VLAN_INFO_BRENTRY. Thanks, Petr _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
