Messages in this thread | | | Date | Sun, 5 Feb 2023 22:25:27 +0300 | Subject | Re: [PATCH net] net: dsa: mt7530: don't change PVC_EG_TAG when CPU port becomes VLAN-aware | From | Arınç ÜNAL <> |
| |
On 5.02.2023 17:07, Vladimir Oltean wrote: > Frank reports that in a mt7530 setup where some ports are standalone and > some are in a VLAN-aware bridge, 8021q uppers of the standalone ports > lose their VLAN tag on xmit, as seen by the link partner. > > This seems to occur because once the other ports join the VLAN-aware > bridge, mt7530_port_vlan_filtering() also calls > mt7530_port_set_vlan_aware(ds, cpu_dp->index), and this affects the way > that the switch processes the traffic of the standalone port. > > Relevant is the PVC_EG_TAG bit. The MT7530 documentation says about it: > > EG_TAG: Incoming Port Egress Tag VLAN Attribution > 0: disabled (system default) > 1: consistent (keep the original ingress tag attribute) > > My interpretation is that this setting applies on the ingress port, and > "disabled" is basically the normal behavior, where the egress tag format > of the packet (tagged or untagged) is decided by the VLAN table > (MT7530_VLAN_EGRESS_UNTAG or MT7530_VLAN_EGRESS_TAG). > > But there is also an option of overriding the system default behavior, > and for the egress tagging format of packets to be decided not by the > VLAN table, but simply by copying the ingress tag format (if ingress was > tagged, egress is tagged; if ingress was untagged, egress is untagged; > aka "consistent). This is useful in 2 scenarios: > > - VLAN-unaware bridge ports will always encounter a miss in the VLAN > table. They should forward a packet as-is, though. So we use > "consistent" there. See commit e045124e9399 ("net: dsa: mt7530: fix > tagged frames pass-through in VLAN-unaware mode"). > > - Traffic injected from the CPU port. The operating system is in god > mode; if it wants a packet to exit as VLAN-tagged, it sends it as > VLAN-tagged. Otherwise it sends it as VLAN-untagged*. > > *This is true only if we don't consider the bridge TX forwarding offload > feature, which mt7530 doesn't support. > > So for now, make the CPU port always stay in "consistent" mode to allow > software VLANs to be forwarded to their egress ports with the VLAN tag > intact, and not stripped. > > Link: https://lore.kernel.org/netdev/trinity-e6294d28-636c-4c40-bb8b-b523521b00be-1674233135062@3c-app-gmx-bs36/ > Fixes: e045124e9399 ("net: dsa: mt7530: fix tagged frames pass-through in VLAN-unaware mode") > Reported-by: Frank Wunderlich <frank-w@public-files.de> > Tested-by: Frank Wunderlich <frank-w@public-files.de> > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested on MT7621AT and MT7623NI boards with MT7530 switch. Both had this issue and this patch fixes it.
Tested-by: Arınç ÜNAL <arinc.unal@arinc9.com>
Unrelated to this, as in it existed before this patch, port@0 hasn't been working at all on my MT7621AT Unielec U7621-06 board and MT7623NI Bananapi BPI-R2.
Packets are sent out from master eth1 fine, the computer receives them. Frames are received on eth1 but nothing shows on the DSA slave interface of port@0. Sounds like malformed frames are received on eth1.
Cheers. Arınç
| |