diff mbox series

[net] net: ethernet: mtk_eth_soc: enable special tag when any MAC uses DSA

Message ID 20230205175331.511332-1-arinc.unal@arinc9.com (mailing list archive)
State New, archived
Headers show
Series [net] net: ethernet: mtk_eth_soc: enable special tag when any MAC uses DSA | expand

Commit Message

Arınç ÜNAL Feb. 5, 2023, 5:53 p.m. UTC 
From: Arınç ÜNAL <arinc.unal@arinc9.com>

The special tag is only enabled when the first MAC uses DSA. However, it
must be enabled when any MAC uses DSA. Change the check accordingly.

This fixes hardware DSA untagging not working on the second MAC of the
MT7621 and MT7623 SoCs, and likely other SoCs too. Therefore, remove the
check that disables hardware DSA untagging for the second MAC of the MT7621
and MT7623 SoCs.

Fixes: a1f47752fd62 ("net: ethernet: mtk_eth_soc: disable hardware DSA untagging for second MAC")
Co-developed-by: Richard van Schagen <richard@routerhints.com>
Signed-off-by: Richard van Schagen <richard@routerhints.com>
Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

Comments

Jakub Kicinski Feb. 7, 2023, 6:56 p.m. UTC | #1 
On Sun,  5 Feb 2023 20:53:31 +0300 arinc9.unal@gmail.com wrote:
> From: Arınç ÜNAL <arinc.unal@arinc9.com>
> 
> The special tag is only enabled when the first MAC uses DSA. However, it
> must be enabled when any MAC uses DSA. Change the check accordingly.
> 
> This fixes hardware DSA untagging not working on the second MAC of the
> MT7621 and MT7623 SoCs, and likely other SoCs too. Therefore, remove the
> check that disables hardware DSA untagging for the second MAC of the MT7621
> and MT7623 SoCs.
> 
> Fixes: a1f47752fd62 ("net: ethernet: mtk_eth_soc: disable hardware DSA untagging for second MAC")

As Paolo pointed out to me off-list this is pretty much a revert of
commit under Fixes. Is this an actual regression fix, or second MAC
as DSA port never worked but now you found a way to make it work?
Arınç ÜNAL Feb. 7, 2023, 8:24 p.m. UTC | #2 
On 7.02.2023 21:56, Jakub Kicinski wrote:
> On Sun,  5 Feb 2023 20:53:31 +0300 arinc9.unal@gmail.com wrote:
>> From: Arınç ÜNAL <arinc.unal@arinc9.com>
>>
>> The special tag is only enabled when the first MAC uses DSA. However, it
>> must be enabled when any MAC uses DSA. Change the check accordingly.
>>
>> This fixes hardware DSA untagging not working on the second MAC of the
>> MT7621 and MT7623 SoCs, and likely other SoCs too. Therefore, remove the
>> check that disables hardware DSA untagging for the second MAC of the MT7621
>> and MT7623 SoCs.
>>
>> Fixes: a1f47752fd62 ("net: ethernet: mtk_eth_soc: disable hardware DSA untagging for second MAC")
> 
> As Paolo pointed out to me off-list this is pretty much a revert of
> commit under Fixes. Is this an actual regression fix, or second MAC
> as DSA port never worked but now you found a way to make it work?

Second MAC as DSA master after hardware DSA untagging was enabled never 
worked. I first disabled it to make the communication work again, then, 
with this patch, I found a way to make it work which is what should've 
been done with the commit for adding hardware DSA untagging support.

Arınç
Arınç ÜNAL Feb. 7, 2023, 8:25 p.m. UTC | #3 
On 7.02.2023 23:24, Arınç ÜNAL wrote:
> On 7.02.2023 21:56, Jakub Kicinski wrote:
>> On Sun,  5 Feb 2023 20:53:31 +0300 arinc9.unal@gmail.com wrote:
>>> From: Arınç ÜNAL <arinc.unal@arinc9.com>
>>>
>>> The special tag is only enabled when the first MAC uses DSA. However, it
>>> must be enabled when any MAC uses DSA. Change the check accordingly.
>>>
>>> This fixes hardware DSA untagging not working on the second MAC of the
>>> MT7621 and MT7623 SoCs, and likely other SoCs too. Therefore, remove the
>>> check that disables hardware DSA untagging for the second MAC of the 
>>> MT7621
>>> and MT7623 SoCs.
>>>
>>> Fixes: a1f47752fd62 ("net: ethernet: mtk_eth_soc: disable hardware 
>>> DSA untagging for second MAC")
>>
>> As Paolo pointed out to me off-list this is pretty much a revert of
>> commit under Fixes. Is this an actual regression fix, or second MAC
>> as DSA port never worked but now you found a way to make it work?
> 
> Second MAC as DSA master after hardware DSA untagging was enabled never 
> worked. I first disabled it to make the communication work again, then, 
> with this patch, I found a way to make it work which is what should've 
> been done with the commit for adding hardware DSA untagging support.

Should both commits be mentioned with Fixes tag?

Arınç
Jakub Kicinski Feb. 7, 2023, 11:58 p.m. UTC | #4 
On Tue, 7 Feb 2023 23:25:32 +0300 Arınç ÜNAL wrote:
> >> As Paolo pointed out to me off-list this is pretty much a revert of
> >> commit under Fixes. Is this an actual regression fix, or second MAC
> >> as DSA port never worked but now you found a way to make it work?  
> > 
> > Second MAC as DSA master after hardware DSA untagging was enabled never 
> > worked. I first disabled it to make the communication work again, then, 
> > with this patch, I found a way to make it work which is what should've 
> > been done with the commit for adding hardware DSA untagging support.  
> 
> Should both commits be mentioned with Fixes tag?

No strong preference, TBH.

The motivation for my question was to try to figure out how long we
should wait with applying this patch. I applied the commit under Fixes
without waiting for a test from Frank, which made me feel a bit guilty
:)
Arınç ÜNAL Feb. 8, 2023, 8:13 a.m. UTC | #5 
On 8.02.2023 02:58, Jakub Kicinski wrote:
> On Tue, 7 Feb 2023 23:25:32 +0300 Arınç ÜNAL wrote:
>>>> As Paolo pointed out to me off-list this is pretty much a revert of
>>>> commit under Fixes. Is this an actual regression fix, or second MAC
>>>> as DSA port never worked but now you found a way to make it work?
>>>
>>> Second MAC as DSA master after hardware DSA untagging was enabled never
>>> worked. I first disabled it to make the communication work again, then,
>>> with this patch, I found a way to make it work which is what should've
>>> been done with the commit for adding hardware DSA untagging support.
>>
>> Should both commits be mentioned with Fixes tag?
> 
> No strong preference, TBH.
> 
> The motivation for my question was to try to figure out how long we
> should wait with applying this patch. I applied the commit under Fixes
> without waiting for a test from Frank, which made me feel a bit guilty
> :)

Oh that's fine, they were going to test on the same hardware I've got 
anyway. You can apply this one whenever is convenient.

Arınç
patchwork-bot+netdevbpf@kernel.org Feb. 8, 2023, 9:10 a.m. UTC | #6 
Hello:

This patch was applied to netdev/net.git (master)
by David S. Miller <davem@davemloft.net>:

On Sun,  5 Feb 2023 20:53:31 +0300 you wrote:
> From: Arınç ÜNAL <arinc.unal@arinc9.com>
> 
> The special tag is only enabled when the first MAC uses DSA. However, it
> must be enabled when any MAC uses DSA. Change the check accordingly.
> 
> This fixes hardware DSA untagging not working on the second MAC of the
> MT7621 and MT7623 SoCs, and likely other SoCs too. Therefore, remove the
> check that disables hardware DSA untagging for the second MAC of the MT7621
> and MT7623 SoCs.
> 
> [...]

Here is the summary with links:
  - [net] net: ethernet: mtk_eth_soc: enable special tag when any MAC uses DSA
    https://git.kernel.org/netdev/net/c/21386e692613

You are awesome, thank you!
Frank Wunderlich Feb. 8, 2023, 2:30 p.m. UTC | #7 
Am 8. Februar 2023 00:58:01 MEZ schrieb Jakub Kicinski <kuba@kernel.org>:
>
>No strong preference, TBH.
>
>The motivation for my question was to try to figure out how long we
>should wait with applying this patch. I applied the commit under Fixes
>without waiting for a test from Frank, which made me feel a bit guilty
>:)

No worry. You don't have to feel guilty for it.

My limited time currently does not allow test all patches in all circumstances...i trust arinc to make it better than before...there are many patches floating around which fixing some corner cases in mtk eth driver. I hope these are applied i had tested and for the others i report a bug when i notice any problem :)

Would be nice if felix' series can be merged for fixing sw vlan on non-dsa mac and the one from vladimir fixing the vlan_aware bridge without breaking dsa port outside the bridge on same gmac.
regards Frank
diff mbox series

Patch

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index f1cb1efc94cf..b5b99f417c86 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -3177,7 +3177,7 @@  static void mtk_gdm_config(struct mtk_eth *eth, u32 config)
 
 		val |= config;
 
-		if (!i && eth->netdev[0] && netdev_uses_dsa(eth->netdev[0]))
+		if (eth->netdev[i] && netdev_uses_dsa(eth->netdev[i]))
 			val |= MTK_GDMA_SPECIAL_TAG;
 
 		mtk_w32(eth, val, MTK_GDMA_FWD_CFG(i));
@@ -3243,8 +3243,7 @@  static int mtk_open(struct net_device *dev)
 	struct mtk_eth *eth = mac->hw;
 	int i, err;
 
-	if ((mtk_uses_dsa(dev) && !eth->prog) &&
-	    !(mac->id == 1 && MTK_HAS_CAPS(eth->soc->caps, MTK_GMAC1_TRGMII))) {
+	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];
 
@@ -3261,8 +3260,7 @@  static int mtk_open(struct net_device *dev)
 		}
 	} else {
 		/* Hardware special tag parsing needs to be disabled if at least
-		 * one MAC does not use DSA, or the second MAC of the MT7621 and
-		 * MT7623 SoCs is being used.
+		 * one MAC does not use DSA.
 		 */
 		u32 val = mtk_r32(eth, MTK_CDMP_IG_CTRL);
 		val &= ~MTK_CDMP_STAG_EN;