From: Arınç ÜNAL <[email protected]>
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 <[email protected]>
Signed-off-by: Richard van Schagen <[email protected]>
Signed-off-by: Arınç ÜNAL <[email protected]>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
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;
--
2.37.2
On Sun, 5 Feb 2023 20:53:31 +0300 [email protected] wrote:
> From: Arınç ÜNAL <[email protected]>
>
> 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?
On 7.02.2023 21:56, Jakub Kicinski wrote:
> On Sun, 5 Feb 2023 20:53:31 +0300 [email protected] wrote:
>> From: Arınç ÜNAL <[email protected]>
>>
>> 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ç
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 [email protected] wrote:
>>> From: Arınç ÜNAL <[email protected]>
>>>
>>> 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ç
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
:)
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ç
Hello:
This patch was applied to netdev/net.git (master)
by David S. Miller <[email protected]>:
On Sun, 5 Feb 2023 20:53:31 +0300 you wrote:
> From: Arınç ÜNAL <[email protected]>
>
> 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!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
Am 8. Februar 2023 00:58:01 MEZ schrieb Jakub Kicinski <[email protected]>:
>
>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