Would there be any interest in creating a DSA driver the the MT7628 (and probably RT305x?) target?
Am I correct in assuming that the current upstream mtk_eth_soc actually works already with the MT7628/88 and "all" it needs is the DSA parts to work without the out of tree driver that we are using now?
When I check the driver code, it does look like there's MT7628/MT7688 specific stuff, so my bet would be: yes.
I have no idea what's involved with getting the subtargets on DSA though.
As there is already upstream support for the MT7530 as e.g. integrated in the MT7621, I guess, there is hope that this driver could be extended for this, not?
No. MT7628's internal switch is a completely different IP and requires a different driver (see esw_rt305x.c).
Special tag support is available, but has to be merged with the VLAN tag (TPID 8100 -> 81xx, where xx is port number), and port-based/802.1Q VLAN share the same table.
Were the DSA driver implemented, its function would be limited.
Maybe see this for starters:
Obviously the MT7621/MT7530 is more powerful and has more features, but what functions would the MT7628 be missing that would make you say "limited"?
As for 802.1Q VLAN, it only supports 16 VIDs, but given the type of hardware that should be sufficient for most use cases. If a user needs more, updating to better/faster hardware is probably a good idea. Since its a hardware limitation this is also in the current (non-dsa) driver.
The special tag look similar to the one used in the MT7530. It seems for a DSA driver to work, it only needs to source-port from the tag which seems to be the same bitfield in both.
The mentioned WIP DSA switch I saw. It is really WIP: it only has .setup .phy_read and .phy_write in the dsa_switch_ops and no other functionality.
I will have a go at this: it will be a good exercise to get a much deeper understanding of what is really the hearth of a router/switch.
Please, also look at this: https://github.com/rettichschnidi/linux/commits/gardena/rs/v5.10.42-mt7688
Is there any information available about this code block:
for (i = 0; i < 5; i++) {
mii_mgr_write(priv, i, 31, 0x8000);
mii_mgr_write(priv, i, 0, 0x3100);
mii_mgr_write(priv, i, 30, 0xa000);
mii_mgr_write(priv, i, 31, 0xa000);
mii_mgr_write(priv, i, 16, 0x0606);
mii_mgr_write(priv, i, 23, 0x0f0e);
mii_mgr_write(priv, i, 24, 0x1610);
mii_mgr_write(priv, i, 30, 0x1f15);
mii_mgr_write(priv, i, 28, 0x6111);
mii_mgr_write(priv, i, 31, 0x2000);
mii_mgr_write(priv, i, 26, 0x0000);
}
/* 100Base AOI setting */
mii_mgr_write(priv, 0, 31, 0x5000);
mii_mgr_write(priv, 0, 19, 0x004a);
mii_mgr_write(priv, 0, 20, 0x015a);
mii_mgr_write(priv, 0, 21, 0x00ee);
mii_mgr_write(priv, 0, 22, 0x0033);
mii_mgr_write(priv, 0, 23, 0x020a);
mii_mgr_write(priv, 0, 24, 0x0000);
mii_mgr_write(priv, 0, 25, 0x024a);
mii_mgr_write(priv, 0, 26, 0x035a);
mii_mgr_write(priv, 0, 27, 0x02ee);
mii_mgr_write(priv, 0, 28, 0x0233);
mii_mgr_write(priv, 0, 29, 0x000a);
mii_mgr_write(priv, 0, 30, 0x0000);
It seems we just copy this from driver to driver 
No, but I think it make sense to bring it as done here https://github.com/u-boot/u-boot/blob/master/drivers/net/mt7628-eth.c#L284
Because this code was reviewed by mtk developers and it is not different from original code https://develop.nagtech.ru/public-source/SNR-CPE/-/blob/master/linux-3.4.x/drivers/net/raeth/ra_esw_rt305x.c#L263 based on latest SDK 5.0.0.0
Also I think that current mtk_eth_soc code (19.07, 21.02 branches) has some problems related common system stability on MT7628 (https://github.com/openwrt/mt76/issues/628). I made some investigation on 21.02 branch:
I would actually prefer to remove the MT7628 stuff from the upstream mtl_eth_soc code. Make that driver for the MT7621/23 (probably 22; I'm not really familiar with that one).
Create a simple ethernet driver and move the rest into the dsa switch. More or less like its done on the lanqiq xrx200 with the gswip dsa driver. Probably make a separate PHY driver as well. It looks like the RT3052 and the RT5350 have the same PHY and the MT76x8 has a different PHY.
For Flow Offload (HW NAT) the MT7620 already has the newer engine vs the RT3052 so probably the mtk_eth_soc should also deal the the MT7620...but that also means it needs to keep the code for the PDMA vs QDMA.
It is good idea. MII bus is available via MT7628 ESW registers. Also please look at this comment line: https://develop.nagtech.ru/public-source/SNR-CPE/-/blob/master/linux-3.4.x/drivers/net/raeth/ra_eth.c#L24
With a little luck I should have at least some kind of proof of concept working tomorrow, latest the day after. Using the Mediatek switch tag I hope: from the documentation its still not 100% clear if it works on the TX side: Only send traffic out of the inserted port and thereby being able to isolate all the ports without the need of VLAN. Even the switch seems to always insert a PVID so probably we need to use double tagging to have vlan_filtering working and being able to have tagged and untagged frames on the same port.
Just a small update: made a separate PHY driver; not sure how to properly implement it. It’s called 5 times but I don’t think I should do a complete init 5 times.
Have a “new” (based on the uboot driver) simple ethernet driver. Very basic: init dma, open, close, xmit and receive based on interrupts. No Dim yet. Do I need for a 100M frame engine?
Basic DSA with the Mediatek (Ralink) tags. More testing needed to TX; not sure if only using the port I inject or because the Mac is already in the FDB inside the switch. On that note: should I disable auto learning and use the CPU? In which case how to handle aging? Actually aging update: when the same MAC is seen again the timer restarts, right?
As usual: documentation on how and what to implement is a problem and every DSA/Ethernet driver seems to handle things differently.
Hi, thanks you for your's work!
This requires the use of delayed tx/rx interrupts and also increasing perfomance. See this commit 1 and commit 2 for details. I suspect this will also have a positive effect on WiFi.
Alas, although I studied the driver code, I am still not so well versed in the matter. Maybe it makes sense to do it in the same way as lantiq or MT7621 DSA?
Hi, @drbrains ! Do you have any success?
I am also interested in implementing DSA for MT7628 and planned to do it myself until you opened this topic. I lack experience in developing for DSA, so the process takes a long time.
What about using core phy linux implementation? Initial initialization in dsa driver can be done in the same way as in original driver.
I am making progress. But as I was afraid of: the "Ralink TAG" is only to receive and can't be used to steer a packet to a specific port. This still needs to be done via VLAN "membership" and/or by programming the specific MAC into the FDB with a specific VLAN and Port.
I just received a RT5350 board; just the board, no power supply or case, which I found online for a few bucks. The RT5350 seems to be the most simple switch in the RT305x/MT76x8 family. If it works on that one, its very likely that it also works on the RT305x (even if I don't have testing device myself).
Additional challenges with DSA: a lot has changed between 5.10.x and 5.16 and not I am not sure what is already back ported and what not, so that takes some trial and error. Simple things like "bridge number" to assign a different "default" PVID to a bridge in case none is specified doesn't exist in the 5.10.90 kernel.
As for the PHY driver: Yes, even I have a proof of concept driver, the generic phy works and just the init can be done from the DSA driver.
I think I have worked out most of the issues and will push a beta driver onto my GitHub soon. Including a "new" ethernet driver. The mtk_eth_soc doesn't work properly, same issues as before show up: dma eth0 timeout on the master build; (the stable 21.02.1 on kernel 5.4 doesn't have that problem strangely enough).
Are you shure? From this code looks like it should work.
Not sure which part of the code you mean. The link goes to a part which is relevant to make it vlan aware or vlan unaware. The original code also only uses it for receive:
#if defined (CONFIG_RAETH_SPECIAL_TAG)
#if defined (CONFIG_MT7530_GSW)
#define ESW_TAG_ID 0x00
#else
#define ESW_TAG_ID 0x81
#endif
// port0: 0x8100 => 0x8100 0001
// port1: 0x8101 => 0x8100 0002
// port2: 0x8102 => 0x8100 0003
// port3: 0x8103 => 0x8100 0004
// port4: 0x8104 => 0x8100 0005
// port5: 0x8105 => 0x8100 0006
veth = vlan_eth_hdr(rx_skb);
if ((veth->h_vlan_proto & 0xFF) == ESW_TAG_ID) {
veth->h_vlan_TCI = htons((((veth->h_vlan_proto >> 8) & 0xF) + 1));
veth->h_vlan_proto = __constant_htons(ETH_P_8021Q);
rx_skb->protocol = veth->h_vlan_proto;
}
#endif
But since the MT76x8 has an additional bit for the SPECIAL_TAG (vs the RT3052 or RT5350) I was hoping there were some improvements. In register Switch Global Control 2 (0x101100E4), they added BIT(23):
Special Tag enable
0: default; RX special tag is enabled according to the global control bit- CPU_TPID_EN. TX special tag is enabled according to the per-port TX_CPU_TPID_BIT_MAP
1: CPU_TPID_EN is not used Both TX and RX special tag feature are decided by the per-port TX_CPU_TPID_BMAP
TX_CPU_TPID_BMAP:
0 default 0x8100
1 x0810x depending on TX/RX usage
CPU_TPID_EN (bit 10):
0: disable CPU_TPID 0x8100
1: enable CPU_TPID 0x810x
Also enabled in the frame engine (SDM_CON register). If I insert the TAG on egress it only gets removed on port 0, which makes sense, since then it looks like a "normal" 0x8100 TPID. Anything else will actually transmit out of the port, which doesn't work on the receiving side and doesn't get untagged by the switch itself. I tried with different settings for the VID, having that 0x000, 0x001 (the PVID) or even something random...the TAG doesn't get removed on egress which is a no-go for VLAN unaware settings.
Thanks for clarify! Judging by the description of the bits, this should be enough. So it doesn't work?
Have a look at the datasheets for the RT3052 and RT5350, they all are very similar to the switch in the MT76x8, but lack the BIT(23) which is indicated as "reserved" on those older SoCs. So for sure those will not work for egress. The MT76x8 is slightly different which would suggest that it could maybe do something on egress (steer the packet to a port), but the TAG is not removed even when the port is selected as "untagged". It seems the switch doesn't recognise the egress 0x810x TPID vs 0x8100, so for now I am not getting that to work.
If I selected NOT to untag and select to also transmit the TPID-TAG on other ports besides the CPU I can actually see forwarded traffic being tagged with their incoming port (ie. LAN - LAN direct port-port). "See" means WireGuard will show me the packets, but my PC doesn't understand what to do with a Ethernet Type (the TPID) of 0x810x.
Besides, my ultimate goal would be to replace the switch / ethernet driver for the whole range RT305x/RT5350/MT76x8, which means I will try to have common solution for all.