From: Felix Fietkau <[email protected]>
Through testing I found out that hardware vlan rx offload support seems to
have some hardware issues. At least when using multiple MACs and when receiving
tagged packets on the secondary MAC, the hardware can sometimes start to emit
wrong tags on the first MAC as well.
In order to avoid such issues, drop the feature configuration and use the
offload feature only for DSA hardware untagging on MT7621/MT7622 devices which
only use one MAC.
Tested-by: Frank Wunderlich <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
Signed-off-by: Frank Wunderlich <[email protected]>
---
used felix Patch as base and ported up to 6.3-rc6 which seems to get lost
and the original bug is not handled again.
it reverts changes from vladimirs patch
1a3245fe0cf8 net: ethernet: mtk_eth_soc: fix DSA TX tag hwaccel for switch port 0
tested this on bananapi-r3 on non-dsa gmac1 and dsa aware eth0 (wan).
on both vlan is working, but maybe it breaks HW-vlan-untagging
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 105 ++++++++------------
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 1 -
2 files changed, 39 insertions(+), 67 deletions(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index e14050e17862..20c60cee6aa7 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1921,9 +1921,7 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
while (done < budget) {
unsigned int pktlen, *rxdcsum;
- bool has_hwaccel_tag = false;
struct net_device *netdev;
- u16 vlan_proto, vlan_tci;
dma_addr_t dma_addr;
u32 hash, reason;
int mac = 0;
@@ -2058,31 +2056,16 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
skb_checksum_none_assert(skb);
skb->protocol = eth_type_trans(skb, netdev);
- if (netdev->features & NETIF_F_HW_VLAN_CTAG_RX) {
- if (MTK_HAS_CAPS(eth->soc->caps, MTK_NETSYS_V2)) {
- if (trxd.rxd3 & RX_DMA_VTAG_V2) {
- vlan_proto = RX_DMA_VPID(trxd.rxd4);
- vlan_tci = RX_DMA_VID(trxd.rxd4);
- has_hwaccel_tag = true;
- }
- } else if (trxd.rxd2 & RX_DMA_VTAG) {
- vlan_proto = RX_DMA_VPID(trxd.rxd3);
- vlan_tci = RX_DMA_VID(trxd.rxd3);
- has_hwaccel_tag = true;
- }
- }
-
/* When using VLAN untagging in combination with DSA, the
* hardware treats the MTK special tag as a VLAN and untags it.
*/
- if (has_hwaccel_tag && netdev_uses_dsa(netdev)) {
- unsigned int port = vlan_proto & GENMASK(2, 0);
+ if (!MTK_HAS_CAPS(eth->soc->caps, MTK_NETSYS_V2) &&
+ (trxd.rxd2 & RX_DMA_VTAG) && netdev_uses_dsa(netdev)) {
+ unsigned int port = RX_DMA_VPID(trxd.rxd3) & GENMASK(2, 0);
if (port < ARRAY_SIZE(eth->dsa_meta) &&
eth->dsa_meta[port])
skb_dst_set_noref(skb, ð->dsa_meta[port]->dst);
- } else if (has_hwaccel_tag) {
- __vlan_hwaccel_put_tag(skb, htons(vlan_proto), vlan_tci);
}
if (reason == MTK_PPE_CPU_REASON_HIT_UNBIND_RATE_REACHED)
@@ -2910,29 +2893,11 @@ static netdev_features_t mtk_fix_features(struct net_device *dev,
static int mtk_set_features(struct net_device *dev, netdev_features_t features)
{
- struct mtk_mac *mac = netdev_priv(dev);
- struct mtk_eth *eth = mac->hw;
netdev_features_t diff = dev->features ^ features;
- int i;
if ((diff & NETIF_F_LRO) && !(features & NETIF_F_LRO))
mtk_hwlro_netdev_disable(dev);
- /* Set RX VLAN offloading */
- if (!(diff & NETIF_F_HW_VLAN_CTAG_RX))
- return 0;
-
- mtk_w32(eth, !!(features & NETIF_F_HW_VLAN_CTAG_RX),
- MTK_CDMP_EG_CTRL);
-
- /* sync features with other MAC */
- for (i = 0; i < MTK_MAC_COUNT; i++) {
- if (!eth->netdev[i] || eth->netdev[i] == dev)
- continue;
- eth->netdev[i]->features &= ~NETIF_F_HW_VLAN_CTAG_RX;
- eth->netdev[i]->features |= features & NETIF_F_HW_VLAN_CTAG_RX;
- }
-
return 0;
}
@@ -3250,30 +3215,6 @@ static int mtk_open(struct net_device *dev)
struct mtk_eth *eth = mac->hw;
int i, err;
- if (mtk_uses_dsa(dev) && !eth->prog) {
- for (i = 0; i < ARRAY_SIZE(eth->dsa_meta); i++) {
- struct metadata_dst *md_dst = eth->dsa_meta[i];
-
- if (md_dst)
- continue;
-
- md_dst = metadata_dst_alloc(0, METADATA_HW_PORT_MUX,
- GFP_KERNEL);
- if (!md_dst)
- return -ENOMEM;
-
- md_dst->u.port_info.port_id = i;
- eth->dsa_meta[i] = md_dst;
- }
- } else {
- /* Hardware special tag parsing needs to be disabled if at least
- * one MAC does not use DSA.
- */
- u32 val = mtk_r32(eth, MTK_CDMP_IG_CTRL);
- val &= ~MTK_CDMP_STAG_EN;
- mtk_w32(eth, val, MTK_CDMP_IG_CTRL);
- }
-
err = phylink_of_phy_connect(mac->phylink, mac->of_node, 0);
if (err) {
netdev_err(dev, "%s: could not attach PHY: %d\n", __func__,
@@ -3312,6 +3253,39 @@ static int mtk_open(struct net_device *dev)
phylink_start(mac->phylink);
netif_tx_start_all_queues(dev);
+ if (MTK_HAS_CAPS(eth->soc->caps, MTK_NETSYS_V2))
+ return 0;
+
+ if (mtk_uses_dsa(dev) && !eth->prog) {
+ for (i = 0; i < ARRAY_SIZE(eth->dsa_meta); i++) {
+ struct metadata_dst *md_dst = eth->dsa_meta[i];
+
+ if (md_dst)
+ continue;
+
+ md_dst = metadata_dst_alloc(0, METADATA_HW_PORT_MUX,
+ GFP_KERNEL);
+ if (!md_dst)
+ return -ENOMEM;
+
+ md_dst->u.port_info.port_id = i;
+ eth->dsa_meta[i] = md_dst;
+ }
+ } else {
+ /* Hardware special tag parsing needs to be disabled if at least
+ * one MAC does not use DSA.
+ */
+ u32 val = mtk_r32(eth, MTK_CDMP_IG_CTRL);
+ val &= ~MTK_CDMP_STAG_EN;
+ mtk_w32(eth, val, MTK_CDMP_IG_CTRL);
+
+ val = mtk_r32(eth, MTK_CDMQ_IG_CTRL);
+ val &= ~MTK_CDMQ_STAG_EN;
+ mtk_w32(eth, val, MTK_CDMQ_IG_CTRL);
+
+ mtk_w32(eth, 0, MTK_CDMP_EG_CTRL);
+ }
+
return 0;
}
@@ -3796,10 +3770,9 @@ static int mtk_hw_init(struct mtk_eth *eth, bool reset)
if (!MTK_HAS_CAPS(eth->soc->caps, MTK_NETSYS_V2)) {
val = mtk_r32(eth, MTK_CDMP_IG_CTRL);
mtk_w32(eth, val | MTK_CDMP_STAG_EN, MTK_CDMP_IG_CTRL);
- }
- /* Enable RX VLan Offloading */
- mtk_w32(eth, 1, MTK_CDMP_EG_CTRL);
+ mtk_w32(eth, 1, MTK_CDMP_EG_CTRL);
+ }
/* set interrupt delays based on current Net DIM sample */
mtk_dim_rx(ð->rx_dim.work);
@@ -4437,7 +4410,7 @@ static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
eth->netdev[id]->hw_features |= NETIF_F_LRO;
eth->netdev[id]->vlan_features = eth->soc->hw_features &
- ~(NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_RX);
+ ~NETIF_F_HW_VLAN_CTAG_TX;
eth->netdev[id]->features |= eth->soc->hw_features;
eth->netdev[id]->ethtool_ops = &mtk_ethtool_ops;
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 084a6badef6d..ac57dc87c59a 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -48,7 +48,6 @@
#define MTK_HW_FEATURES (NETIF_F_IP_CSUM | \
NETIF_F_RXCSUM | \
NETIF_F_HW_VLAN_CTAG_TX | \
- NETIF_F_HW_VLAN_CTAG_RX | \
NETIF_F_SG | NETIF_F_TSO | \
NETIF_F_TSO6 | \
NETIF_F_IPV6_CSUM |\
--
2.34.1
On 16.04.2023 12:10, Frank Wunderlich wrote:
> From: Felix Fietkau <[email protected]>
>
> Through testing I found out that hardware vlan rx offload support seems to
> have some hardware issues. At least when using multiple MACs and when receiving
> tagged packets on the secondary MAC, the hardware can sometimes start to emit
> wrong tags on the first MAC as well.
>
> In order to avoid such issues, drop the feature configuration and use the
> offload feature only for DSA hardware untagging on MT7621/MT7622 devices which
> only use one MAC.
MT7621 devices most certainly use both MACs.
>
> Tested-by: Frank Wunderlich <[email protected]>
> Signed-off-by: Felix Fietkau <[email protected]>
> Signed-off-by: Frank Wunderlich <[email protected]>
> ---
> used felix Patch as base and ported up to 6.3-rc6 which seems to get lost
> and the original bug is not handled again.
>
> it reverts changes from vladimirs patch
>
> 1a3245fe0cf8 net: ethernet: mtk_eth_soc: fix DSA TX tag hwaccel for switch port 0
Do I understand correctly that this is considered being reverted because
the feature it fixes is being removed?
Arınç
Am 16. April 2023 11:52:31 MESZ schrieb "Arınç ÜNAL" <[email protected]>:
>On 16.04.2023 12:10, Frank Wunderlich wrote:
>> From: Felix Fietkau <[email protected]>
>>
>> Through testing I found out that hardware vlan rx offload support seems to
>> have some hardware issues. At least when using multiple MACs and when receiving
>> tagged packets on the secondary MAC, the hardware can sometimes start to emit
>> wrong tags on the first MAC as well.
>>
>> In order to avoid such issues, drop the feature configuration and use the
>> offload feature only for DSA hardware untagging on MT7621/MT7622 devices which
>> only use one MAC.
>
>MT7621 devices most certainly use both MACs.
>
>>
>> Tested-by: Frank Wunderlich <[email protected]>
>> Signed-off-by: Felix Fietkau <[email protected]>
>> Signed-off-by: Frank Wunderlich <[email protected]>
>> ---
>> used felix Patch as base and ported up to 6.3-rc6 which seems to get lost
>> and the original bug is not handled again.
>>
>> it reverts changes from vladimirs patch
>>
>> 1a3245fe0cf8 net: ethernet: mtk_eth_soc: fix DSA TX tag hwaccel for switch port 0
>
>Do I understand correctly that this is considered being reverted because the feature it fixes is being removed?
As far as i understood, vladimirs patch fixes one
cornercase of hw rx offload where felix original
patch was fixing more..sent it as rft to you to test
if your bug (which vladimir fixed) is not coming in
again. If it does we can try to merge both
attempts. But current state has broken vlan on
bpi-r3 non-dsa gmac1 (sfp-wan).
>Arınç
regards Frank
On 16.04.2023 13:15, Frank Wunderlich wrote:
> Am 16. April 2023 11:52:31 MESZ schrieb "Arınç ÜNAL" <[email protected]>:
>> On 16.04.2023 12:10, Frank Wunderlich wrote:
>>> From: Felix Fietkau <[email protected]>
>>>
>>> Through testing I found out that hardware vlan rx offload support seems to
>>> have some hardware issues. At least when using multiple MACs and when receiving
>>> tagged packets on the secondary MAC, the hardware can sometimes start to emit
>>> wrong tags on the first MAC as well.
>>>
>>> In order to avoid such issues, drop the feature configuration and use the
>>> offload feature only for DSA hardware untagging on MT7621/MT7622 devices which
>>> only use one MAC.
>>
>> MT7621 devices most certainly use both MACs.
>>
>>>
>>> Tested-by: Frank Wunderlich <[email protected]>
>>> Signed-off-by: Felix Fietkau <[email protected]>
>>> Signed-off-by: Frank Wunderlich <[email protected]>
>>> ---
>>> used felix Patch as base and ported up to 6.3-rc6 which seems to get lost
>>> and the original bug is not handled again.
>>>
>>> it reverts changes from vladimirs patch
>>>
>>> 1a3245fe0cf8 net: ethernet: mtk_eth_soc: fix DSA TX tag hwaccel for switch port 0
>>
>> Do I understand correctly that this is considered being reverted because the feature it fixes is being removed?
>
> As far as i understood, vladimirs patch fixes one
> cornercase of hw rx offload where felix original
> patch was fixing more..sent it as rft to you to test
> if your bug (which vladimir fixed) is not coming in
> again. If it does we can try to merge both
> attempts. But current state has broken vlan on
> bpi-r3 non-dsa gmac1 (sfp-wan).
I tested this patch on MT7621AT and MT7623NI SoCs on the current
linux-next. Port 0 keeps working fine.
So when you use VLANs on non-DSA gmac1, network connectivity is broken?
I've got an MT7621AT device which gmac1 is connected to an external phy
(sfp-wan, the same case as yours). I'll test VLANs there. See if MT7621
is affected by this as well since the patch log here states this feature
is kept enabled for MT7621 because only gmac0 is used which is false.
Arınç
> Gesendet: Sonntag, 16. April 2023 um 12:55 Uhr
> Von: "Arınç ÜNAL" <[email protected]>
> On 16.04.2023 13:15, Frank Wunderlich wrote:
> > Am 16. April 2023 11:52:31 MESZ schrieb "Arınç ÜNAL" <[email protected]>:
> >> On 16.04.2023 12:10, Frank Wunderlich wrote:
> >>> From: Felix Fietkau <[email protected]>
> >>>
> >>> Through testing I found out that hardware vlan rx offload support seems to
> >>> have some hardware issues. At least when using multiple MACs and when receiving
> >>> tagged packets on the secondary MAC, the hardware can sometimes start to emit
> >>> wrong tags on the first MAC as well.
> >>>
> >>> In order to avoid such issues, drop the feature configuration and use the
> >>> offload feature only for DSA hardware untagging on MT7621/MT7622 devices which
> >>> only use one MAC.
> >>
> >> MT7621 devices most certainly use both MACs.
> >>
> >>>
> >>> Tested-by: Frank Wunderlich <[email protected]>
> >>> Signed-off-by: Felix Fietkau <[email protected]>
> >>> Signed-off-by: Frank Wunderlich <[email protected]>
> >>> ---
> >>> used felix Patch as base and ported up to 6.3-rc6 which seems to get lost
> >>> and the original bug is not handled again.
> >>>
> >>> it reverts changes from vladimirs patch
> >>>
> >>> 1a3245fe0cf8 net: ethernet: mtk_eth_soc: fix DSA TX tag hwaccel for switch port 0
> >>
> >> Do I understand correctly that this is considered being reverted because the feature it fixes is being removed?
> >
> > As far as i understood, vladimirs patch fixes one
> > cornercase of hw rx offload where felix original
> > patch was fixing more..sent it as rft to you to test
> > if your bug (which vladimir fixed) is not coming in
> > again. If it does we can try to merge both
> > attempts. But current state has broken vlan on
> > bpi-r3 non-dsa gmac1 (sfp-wan).
>
> I tested this patch on MT7621AT and MT7623NI SoCs on the current
> linux-next. Port 0 keeps working fine.
looks good so far ;)
> So when you use VLANs on non-DSA gmac1, network connectivity is broken?
the vlan does not work...it looks it is untagged on rx path. i see tagged frames on the other
end, send tagged back and these are not received tagged on the mac...this behaviour has brought
me to felix patch i had rebased here. the non-vlan traffic is not affected.
> I've got an MT7621AT device which gmac1 is connected to an external phy
> (sfp-wan, the same case as yours). I'll test VLANs there. See if MT7621
> is affected by this as well since the patch log here states this feature
> is kept enabled for MT7621 because only gmac0 is used which is false.
good idea :)
> Arınç
On 16.04.2023 12:10, Frank Wunderlich wrote:
> From: Felix Fietkau <[email protected]>
>
> Through testing I found out that hardware vlan rx offload support seems to
> have some hardware issues. At least when using multiple MACs and when receiving
> tagged packets on the secondary MAC, the hardware can sometimes start to emit
> wrong tags on the first MAC as well.
>
> In order to avoid such issues, drop the feature configuration and use the
> offload feature only for DSA hardware untagging on MT7621/MT7622 devices which
> only use one MAC.
I would change this part to:
In order to avoid such issues, drop the feature configuration and use
the offload feature only for DSA hardware untagging on MT7621/MT7622
devices where this feature works properly.
I tried this on linux-next with my defconfig and devicetree [0], on a
MikroTik RouterBOARD 760iGS. I tried both VLAN configurations possible,
VLAN subinterface of the eth1 interface, and bridge VLAN filtering on a
bridge with eth1 joined. In both cases, both sides receive VLAN tagged
frames whether this patch is applied or not.
My computer is plugged to the RJ45 SFP module which is connected to the
Qualcomm Atheros AR8031/AR8033 PHY which is connected to MT7621's gmac1.
My computer:
sudo ip l add link enp9s0 name enp9s0.10 type vlan id 10
sudo ip a add 192.168.3.2/24 dev enp9s0.10
sudo ip l set up enp9s0
MT7621 VLAN subinterface test:
ip l add l eth1 name eth1.10 type vlan id 10
ip a add 192.168.3.1/24 dev eth1.10
ip l set up eth1
ip l set up eth1.10
ping 192.168.3.2
MT7621 bridge VLAN filtering test:
ip l del eth1.10
ip l add br0 type bridge vlan_filtering 1
ip l set eth1 master br0
bridge v add vid 10 dev eth1
bridge v add vid 10 dev br0 self
ip l add l br0 name br0.10 type vlan id 10
ip a add 192.168.3.1/24 dev br0.10
ip l set up br0
ip l set up br0.10
ping 192.168.3.2
In conclusion, it's not that VLAN RX offloading is being kept enabled
for MT7621 because it uses only one MAC. It's because it just works. I
am assuming this is the same case for MT7622.
With that:
Tested-by: Arınç ÜNAL <[email protected]>
[0] https://github.com/arinc9/linux/commits/test-on-linuxnext
Arınç