Message ID | 20160123204416.GC10826@n2100.arm.linux.org.uk |
---|---|
State | RFC, archived |
Delegated to: | David Miller |
Headers | show |
> This shows port 0 is on vlan 0, but it should default to vlan 1 when > no vlans are configured. The patch below should at least allow some > diagnosis of what's being requested, and when. > > diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c > index a43354ed0607..8a9cf67eb16d 100644 > --- a/drivers/net/dsa/mv88e6xxx.c > +++ b/drivers/net/dsa/mv88e6xxx.c > @@ -1511,6 +1511,9 @@ int mv88e6xxx_port_vlan_add(struct dsa_switch *ds, int port, > u16 vid; > int err = 0; > > + printk("%s: port %d vid %u-%u flags %x\n", > + __func__, port, vlan->vid_begin, vlan->vid_end, vlan->flags); > + Hi Russell Never called. So i guess we have a kernel configuration difference. I don't have CONFIG_BRIDGE_VLAN_FILTERING. But DSA should not rely on this option for correct operation. Andrew
On Sat, Jan 23, 2016 at 11:12:32PM +0100, Andrew Lunn wrote: > > This shows port 0 is on vlan 0, but it should default to vlan 1 when > > no vlans are configured. The patch below should at least allow some > > diagnosis of what's being requested, and when. > > > > diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c > > index a43354ed0607..8a9cf67eb16d 100644 > > --- a/drivers/net/dsa/mv88e6xxx.c > > +++ b/drivers/net/dsa/mv88e6xxx.c > > @@ -1511,6 +1511,9 @@ int mv88e6xxx_port_vlan_add(struct dsa_switch *ds, int port, > > u16 vid; > > int err = 0; > > > > + printk("%s: port %d vid %u-%u flags %x\n", > > + __func__, port, vlan->vid_begin, vlan->vid_end, vlan->flags); > > + > > Hi Russell > > Never called. > > So i guess we have a kernel configuration difference. > > I don't have CONFIG_BRIDGE_VLAN_FILTERING. Yep, confirmed. When i enable this option, and VLAN_8021Q which it depends on, i then have a working bridge. Andrew
On Sat, Jan 23, 2016 at 11:23:26PM +0100, Andrew Lunn wrote: > On Sat, Jan 23, 2016 at 11:12:32PM +0100, Andrew Lunn wrote: > > Hi Russell > > > > Never called. > > > > So i guess we have a kernel configuration difference. > > > > I don't have CONFIG_BRIDGE_VLAN_FILTERING. > > Yep, confirmed. When i enable this option, and VLAN_8021Q which it > depends on, i then have a working bridge. It sounds like Vivien urgently needs to do some extra work to fix the patches that created all this broken-ness, or we need to ask davem to revert back to a known good working state.
Hi Russell, Russell King - ARM Linux <linux@arm.linux.org.uk> writes: > On Sat, Jan 23, 2016 at 11:23:26PM +0100, Andrew Lunn wrote: >> On Sat, Jan 23, 2016 at 11:12:32PM +0100, Andrew Lunn wrote: >> > Hi Russell >> > >> > Never called. >> > >> > So i guess we have a kernel configuration difference. >> > >> > I don't have CONFIG_BRIDGE_VLAN_FILTERING. >> >> Yep, confirmed. When i enable this option, and VLAN_8021Q which it >> depends on, i then have a working bridge. > > It sounds like Vivien urgently needs to do some extra work to fix > the patches that created all this broken-ness, or we need to ask > davem to revert back to a known good working state. Indeed hardware bridging currently relies on 802.1Q and VLAN filtering enabled. I will work on this asap. Thanks, -v
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c index a43354ed0607..8a9cf67eb16d 100644 --- a/drivers/net/dsa/mv88e6xxx.c +++ b/drivers/net/dsa/mv88e6xxx.c @@ -1511,6 +1511,9 @@ int mv88e6xxx_port_vlan_add(struct dsa_switch *ds, int port, u16 vid; int err = 0; + printk("%s: port %d vid %u-%u flags %x\n", + __func__, port, vlan->vid_begin, vlan->vid_end, vlan->flags); + mutex_lock(&ps->smi_mutex); for (vid = vlan->vid_begin; vid <= vlan->vid_end; ++vid) {