diff mbox series

mt7530 fix mt7530_fdb_write vid missing ivl bit

Message ID 20210716152213.4213-1-ericwouds@gmail.com (mailing list archive)
State Superseded
Delegated to: Netdev Maintainers
Headers show
Series mt7530 fix mt7530_fdb_write vid missing ivl bit | expand

Checks

Context Check Description
netdev/cover_letter success Link
netdev/fixes_present success Link
netdev/patch_count success Link
netdev/tree_selection success Guessed tree name to be net-next
netdev/subject_prefix warning Target tree name not specified in the subject
netdev/cc_maintainers success CCed 12 of 12 maintainers
netdev/source_inline success Was 0 now: 0
netdev/verify_signedoff success Link
netdev/module_param success Was 0 now: 0
netdev/build_32bit success Errors and warnings before: 0 this patch: 0
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/verify_fixes success Link
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 14 lines checked
netdev/build_allmodconfig_warn success Errors and warnings before: 0 this patch: 0
netdev/header_inline success Link

Commit Message

Eric Woudstra July 16, 2021, 3:22 p.m. UTC 
From: Eric Woudstra <37153012+ericwoud@users.noreply.github.com>

According to reference guides mt7530 (mt7620) and mt7531:

NOTE: When IVL is reset, MAC[47:0] and FID[2:0] will be used to 
read/write the address table. When IVL is set, MAC[47:0] and CVID[11:0] 
will be used to read/write the address table.

Since the function only fills in CVID and no FID, we need to set the
IVL bit. The existing code does not set it.

This is a fix for the issue I dropped here earlier:

http://lists.infradead.org/pipermail/linux-mediatek/2021-June/025697.html

With this patch, it is now possible to delete the 'self' fdb entry
manually. However, wifi roaming still has the same issue, the entry
does not get deleted automatically. Wifi roaming also needs a fix
somewhere else to function correctly in combination with vlan.

Signed-off-by: Eric Woudstra <37153012+ericwoud@users.noreply.github.com>
---
 drivers/net/dsa/mt7530.c | 1 +
 drivers/net/dsa/mt7530.h | 1 +
 2 files changed, 2 insertions(+)

Comments

Andrew Lunn July 16, 2021, 3:32 p.m. UTC | #1 
On Fri, Jul 16, 2021 at 05:22:11PM +0200, ericwouds@gmail.com wrote:
> From: Eric Woudstra <37153012+ericwoud@users.noreply.github.com>
> 
> According to reference guides mt7530 (mt7620) and mt7531:
> 
> NOTE: When IVL is reset, MAC[47:0] and FID[2:0] will be used to 
> read/write the address table. When IVL is set, MAC[47:0] and CVID[11:0] 
> will be used to read/write the address table.
> 
> Since the function only fills in CVID and no FID, we need to set the
> IVL bit. The existing code does not set it.
> 
> This is a fix for the issue I dropped here earlier:
> 
> http://lists.infradead.org/pipermail/linux-mediatek/2021-June/025697.html
> 
> With this patch, it is now possible to delete the 'self' fdb entry
> manually. However, wifi roaming still has the same issue, the entry
> does not get deleted automatically. Wifi roaming also needs a fix
> somewhere else to function correctly in combination with vlan.
> 
> Signed-off-by: Eric Woudstra <37153012+ericwoud@users.noreply.github.com>

Hi Eric

We need a real email address in the Signed-off-by, and the noreply bit
makes me think this will not work.

      Andrew
Qingfang Deng Aug. 8, 2021, 5 p.m. UTC | #2 
On Fri, Jul 16, 2021 at 05:22:11PM +0200, ericwouds@gmail.com wrote:
> From: Eric Woudstra <37153012+ericwoud@users.noreply.github.com>
> 
> According to reference guides mt7530 (mt7620) and mt7531:
> 
> NOTE: When IVL is reset, MAC[47:0] and FID[2:0] will be used to 
> read/write the address table. When IVL is set, MAC[47:0] and CVID[11:0] 
> will be used to read/write the address table.
> 
> Since the function only fills in CVID and no FID, we need to set the
> IVL bit. The existing code does not set it.
> 
> This is a fix for the issue I dropped here earlier:
> 
> http://lists.infradead.org/pipermail/linux-mediatek/2021-June/025697.html
> 
> With this patch, it is now possible to delete the 'self' fdb entry
> manually. However, wifi roaming still has the same issue, the entry
> does not get deleted automatically. Wifi roaming also needs a fix
> somewhere else to function correctly in combination with vlan.

Sorry to bump this up, but I think I identified the issue:

Consider a VLAN-aware bridge br0, with two ports set to different PVIDs:

> bridge vlan
> port         vlan-id
> swp0         1 PVID Egress Untagged
> swp1         2 PVID Egress Untagged

When the bridge core sends a packet to swp1, the packet will be sent to
the CPU port of the switch as untagged because swp1 is set as "Egress
Untagged". However if the switch uses independent VLAN learning, the CPU
port PVID will be used to update the FDB. As we don't change its PVID
(not reasonable to change it anyway), hardware learning may not update
the correct FDB.

A possible solution is always send packets as tagged when serving a
VLAN-aware bridge.

mv88e6xxx has been using hardware learning on CPU port since commit
d82f8ab0d874 ("net: dsa: tag_dsa: offload the bridge forwarding process"),
does it have the same issue?
Vladimir Oltean Aug. 8, 2021, 11:52 p.m. UTC | #3 
On Mon, Aug 09, 2021 at 01:00:24AM +0800, DENG Qingfang wrote:
> On Fri, Jul 16, 2021 at 05:22:11PM +0200, ericwouds@gmail.com wrote:
> > From: Eric Woudstra <37153012+ericwoud@users.noreply.github.com>
> >
> > According to reference guides mt7530 (mt7620) and mt7531:
> >
> > NOTE: When IVL is reset, MAC[47:0] and FID[2:0] will be used to
> > read/write the address table. When IVL is set, MAC[47:0] and CVID[11:0]
> > will be used to read/write the address table.
> >
> > Since the function only fills in CVID and no FID, we need to set the
> > IVL bit. The existing code does not set it.
> >
> > This is a fix for the issue I dropped here earlier:
> >
> > http://lists.infradead.org/pipermail/linux-mediatek/2021-June/025697.html
> >
> > With this patch, it is now possible to delete the 'self' fdb entry
> > manually. However, wifi roaming still has the same issue, the entry
> > does not get deleted automatically. Wifi roaming also needs a fix
> > somewhere else to function correctly in combination with vlan.
>
> Sorry to bump this up, but I think I identified the issue:
>
> Consider a VLAN-aware bridge br0, with two ports set to different PVIDs:
>
> > bridge vlan
> > port         vlan-id
> > swp0         1 PVID Egress Untagged
> > swp1         2 PVID Egress Untagged
>
> When the bridge core sends a packet to swp1, the packet will be sent to
> the CPU port of the switch as untagged because swp1 is set as "Egress
> Untagged". However if the switch uses independent VLAN learning, the CPU
> port PVID will be used to update the FDB.

Sadly the Banana Pi MT7531 reference manual I have does not appear to
cover the DSA tagging header, so I am not actually clear what
MTK_HDR_XMIT_SA_DIS does when not set. Does it default to the CPU port's
value from the PSC register?

If it does, then I expect that your patch 0b69c54c74bc ("net: dsa:
mt7530: enable assisted learning on CPU port") fixes the issue Eric was
seeing, which in turn was caused by your other patch 5e5502e012b8 ("net:
dsa: mt7530: fix roaming from DSA user ports").

> As we don't change its PVID
> (not reasonable to change it anyway), hardware learning may not update
> the correct FDB.
>
> A possible solution is always send packets as tagged when serving a
> VLAN-aware bridge.

So as usual, VLANs put the "hard" in "hardware learning on the CPU port".
I would say "a possible solution is to not attempt to learn from
CPU-injected frames unless they are sent using the tx_fwd_offload
framework"....

>
> mv88e6xxx has been using hardware learning on CPU port since commit
> d82f8ab0d874 ("net: dsa: tag_dsa: offload the bridge forwarding process"),
> does it have the same issue?

...which ensures that bridge data plane packets are always sent to the
CPU port as VLAN-tagged:

br_handle_vlan:

	/* If the skb will be sent using forwarding offload, the assumption is
	 * that the switchdev will inject the packet into hardware together
	 * with the bridge VLAN, so that it can be forwarded according to that
	 * VLAN. The switchdev should deal with popping the VLAN header in
	 * hardware on each egress port as appropriate. So only strip the VLAN
	 * header if forwarding offload is not being used.
	 */
	if (v->flags & BRIDGE_VLAN_INFO_UNTAGGED &&
	    !br_switchdev_frame_uses_tx_fwd_offload(skb))
		__vlan_hwaccel_clear_tag(skb);

Seriously, I expect that a packet injected through the CPU port will,
under normal circumstances, not default not look up the FDB, not update
the FDB, etc etc.

As long as you let the frame analyzer look in depth at the packet you do
need to ensure that it has a valid VLAN ID. Otherwise it is an actual
forwarding correctness issue and not just a "learn in wrong VLAN" issue:

https://patchwork.kernel.org/project/netdevbpf/patch/20210426170411.1789186-6-tobias@waldekranz.com/
diff mbox series

Patch

diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 93136f7e6..9e4df35f9 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -366,6 +366,7 @@  mt7530_fdb_write(struct mt7530_priv *priv, u16 vid,
 	int i;
 
 	reg[1] |= vid & CVID_MASK;
+	reg[1] |= ATA2_IVL;
 	reg[2] |= (aging & AGE_TIMER_MASK) << AGE_TIMER;
 	reg[2] |= (port_mask & PORT_MAP_MASK) << PORT_MAP;
 	/* STATIC_ENT indicate that entry is static wouldn't
diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
index 334d610a5..b19b389ff 100644
--- a/drivers/net/dsa/mt7530.h
+++ b/drivers/net/dsa/mt7530.h
@@ -79,6 +79,7 @@  enum mt753x_bpdu_port_fw {
 #define  STATIC_EMP			0
 #define  STATIC_ENT			3
 #define MT7530_ATA2			0x78
+#define  ATA2_IVL			BIT(15)
 
 /* Register for address table write data */
 #define MT7530_ATWD			0x7c