| Message ID | cover.1597729692.git.landen.chao@mediatek.com |
|---|---|
| Headers | show |
| Series | net-next: dsa: mt7530: add support for MT7531 | expand |
On Tue, 18 Aug 2020 15:14:10 +0800 Landen Chao wrote: > Add new support for MT7531: > > MT7531 is the next generation of MT7530. It is also a 7-ports switch with > 5 giga embedded phys, 2 cpu ports, and the same MAC logic of MT7530. Cpu > port 6 only supports SGMII interface. Cpu port 5 supports either RGMII > or SGMII in different HW sku. Due to SGMII interface support, pll, and > pad setting are different from MT7530. This patch adds different initial > setting, and SGMII phylink handlers of MT7531. > > MT7531 SGMII interface can be configured in following mode: > - 'SGMII AN mode' with in-band negotiation capability > which is compatible with PHY_INTERFACE_MODE_SGMII. > - 'SGMII force mode' without in-bnad negotiation > which is compatible with 10B/8B encoding of > PHY_INTERFACE_MODE_1000BASEX with fixed full-duplex and fixed pause. > - 2.5 times faster clocked 'SGMII force mode' without in-bnad negotiation > which is compatible with 10B/8B encoding of > PHY_INTERFACE_MODE_2500BASEX with fixed full-duplex and fixed pause. > > Signed-off-by: Landen Chao <landen.chao@mediatek.com> > Signed-off-by: Sean Wang <sean.wang@mediatek.com> Please fix these W=1 warnings: ../drivers/net/dsa/mt7530.c:1976:1: warning: no previous prototype for ‘mt7531_sgmii_link_up_force’ [-Wmissing-prototypes] 1976 | mt7531_sgmii_link_up_force(struct dsa_switch *ds, int port, | ^~~~~~~~~~~~~~~~~~~~~~~~~~ ../drivers/net/dsa/mt7530.c:2081:6: warning: no previous prototype for ‘mt7531_sgmii_restart_an’ [-Wmissing-prototypes] 2081 | void mt7531_sgmii_restart_an(struct dsa_switch *ds, int port) | ^~~~~~~~~~~~~~~~~~~~~~~ ../drivers/net/dsa/mt7530.c:1976:1: warning: symbol 'mt7531_sgmii_link_up_force' was not declared. Should it be static? ../drivers/net/dsa/mt7530.c:2081:6: warning: symbol 'mt7531_sgmii_restart_an' was not declared. Should it be static?
On Tue, Aug 18, 2020 at 03:14:07PM +0800, Landen Chao wrote: > Remove 1000baseT_Half to advertise correct hardware capability in > phylink_validate() callback function. Hi Landem This seems like a fix? Please submit it against the net tree, and add a Fixes: tag. Thanks Andrew
On Tue, Aug 18, 2020 at 03:14:08PM +0800, Landen Chao wrote: > Add a structure holding required operations for each device such as device > initialization, PHY port read or write, a checker whether PHY interface is > supported on a certain port, MAC port setup for either bus pad or a > specific PHY interface. > > The patch is done for ready adding a new hardware MT7531. > > Signed-off-by: Landen Chao <landen.chao@mediatek.com> > Signed-off-by: Sean Wang <sean.wang@mediatek.com> > --- > drivers/net/dsa/mt7530.c | 272 +++++++++++++++++++++++++++++---------- > drivers/net/dsa/mt7530.h | 37 +++++- > 2 files changed, 240 insertions(+), 69 deletions(-) > > diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c > index 0fd50798aa42..d30b41725b4d 100644 > --- a/drivers/net/dsa/mt7530.c > +++ b/drivers/net/dsa/mt7530.c > @@ -372,8 +372,9 @@ mt7530_fdb_write(struct mt7530_priv *priv, u16 vid, > mt7530_write(priv, MT7530_ATA1 + (i * 4), reg[i]); > } > > +/* Setup TX circuit incluing relevant PAD and driving */ > static int > -mt7530_pad_clk_setup(struct dsa_switch *ds, int mode) > +mt7530_pad_clk_setup(struct dsa_switch *ds, phy_interface_t interface) > { > struct mt7530_priv *priv = ds->priv; > u32 ncpo1, ssc_delta, trgint, i, xtal; > @@ -387,7 +388,7 @@ mt7530_pad_clk_setup(struct dsa_switch *ds, int mode) > return -EINVAL; > } > > - switch (mode) { > + switch (interface) { > case PHY_INTERFACE_MODE_RGMII: > trgint = 0; > /* PLL frequency: 125MHz */ Do you actually need to support all 4 RGMII modes? ... + goto unsupported; > + break; > + case 6: /* 1st cpu port */ > + if (state->interface != PHY_INTERFACE_MODE_RGMII && > + state->interface != PHY_INTERFACE_MODE_TRGMII) phy_interface_mode_is_rgmii()? Andrew
On Tue, Aug 18, 2020 at 03:14:10PM +0800, Landen Chao wrote: > Add new support for MT7531: > > MT7531 is the next generation of MT7530. It is also a 7-ports switch with > 5 giga embedded phys, 2 cpu ports, and the same MAC logic of MT7530. Cpu > port 6 only supports SGMII interface. Cpu port 5 supports either RGMII > or SGMII in different HW sku. Due to SGMII interface support, pll, and > pad setting are different from MT7530. This patch adds different initial > setting, and SGMII phylink handlers of MT7531. > > MT7531 SGMII interface can be configured in following mode: > - 'SGMII AN mode' with in-band negotiation capability > which is compatible with PHY_INTERFACE_MODE_SGMII. > - 'SGMII force mode' without in-bnad negotiation band > which is compatible with 10B/8B encoding of > PHY_INTERFACE_MODE_1000BASEX with fixed full-duplex and fixed pause. > - 2.5 times faster clocked 'SGMII force mode' without in-bnad negotiation band > +static int mt7531_rgmii_setup(struct mt7530_priv *priv, u32 port, > + phy_interface_t interface) > +{ > + u32 val; > + > + if (!mt7531_is_rgmii_port(priv, port)) { > + dev_err(priv->dev, "RGMII mode is not available for port %d\n", > + port); > + return -EINVAL; > + } > + > + val = mt7530_read(priv, MT7531_CLKGEN_CTRL); > + val |= GP_CLK_EN; > + val &= ~GP_MODE_MASK; > + val |= GP_MODE(MT7531_GP_MODE_RGMII); > + val &= ~(TXCLK_NO_REVERSE | RXCLK_NO_DELAY); > + switch (interface) { > + case PHY_INTERFACE_MODE_RGMII: > + val |= TXCLK_NO_REVERSE; > + val |= RXCLK_NO_DELAY; > + break; > + case PHY_INTERFACE_MODE_RGMII_RXID: > + val |= TXCLK_NO_REVERSE; > + break; > + case PHY_INTERFACE_MODE_RGMII_TXID: > + val |= RXCLK_NO_DELAY; > + break; > + case PHY_INTERFACE_MODE_RGMII_ID: > + break; > + default: > + return -EINVAL; > + } You need to be careful here. If the MAC is doing the RGMII delays, you need to ensure the PHY is not. What interface mode is passed to the PHY? Andrew
On Tue, Aug 18, 2020 at 03:14:11PM +0800, Landen Chao wrote: > Add mt7531 dsa to mt7622-rfb1 board for 5 giga Ethernet ports support. > mt7622 only supports 1 sgmii interface, so either gmac0 or gmac1 can be > configured as sgmii interface. In this patch, change to connet mt7622 connect Andrew
On Tue, Aug 18, 2020 at 03:14:12PM +0800, Landen Chao wrote: > Add mt7531 dsa to bananapi-bpi-r64 board for 5 giga Ethernet ports support. > > Signed-off-by: Landen Chao <landen.chao@mediatek.com> > --- > .../dts/mediatek/mt7622-bananapi-bpi-r64.dts | 44 +++++++++++++++++++ > 1 file changed, 44 insertions(+) > > diff --git a/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts b/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts > index d174ad214857..c57b2571165f 100644 > --- a/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts > +++ b/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts > @@ -143,6 +143,50 @@ > mdio: mdio-bus { > #address-cells = <1>; > #size-cells = <0>; > + > + switch@0 { > + compatible = "mediatek,mt7531"; > + reg = <0>; > + reset-gpios = <&pio 54 0>; > + > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + reg = <0>; > + label = "wan"; > + }; > + > + port@1 { > + reg = <1>; > + label = "lan0"; > + }; > + > + port@2 { > + reg = <2>; > + label = "lan1"; > + }; > + > + port@3 { > + reg = <3>; > + label = "lan2"; > + }; > + > + port@4 { > + reg = <4>; > + label = "lan3"; > + }; > + > + port@6 { > + reg = <6>; > + label = "cpu"; > + ethernet = <&gmac0>; > + phy-mode = "2500base-x"; > + }; Is there any reason why you're not specifying a fixed-link node here? > + }; > + }; > + > }; > }; > > -- > 2.17.1 Thanks, -Vladimir
Just a little typo you've inherited from existing code
>+/* Setup TX circuit incluing relevant PAD and driving */
including
regards Frank
Tested full series on Bananapi-R2+R64 with5.9-rc1 (iperf3 no retransmitts, Throughput >900Mbit/s)
Tested-By: Frank Wunderlich <frank-w@public-files.de>
maybe you can include the port_change_mtu callback you've send me? or do you want to send it separately
regards Frank
Hi, Is port mirroring working? Port mirroring registers on MT7531 have moved, according to bpi's MT7531 reference manual. Please fix that as well.
Hi DENG,
MT7531 mirror port has been fixed by new definition of register base in
header file. The logic of mirror port setting in 7530.c is reused.
@@ -41,6 +42,33 @@ enum mt753x_id {
#define MIRROR_PORT(x) ((x) & 0x7)
#define MIRROR_MASK 0x7
+/* Registers for CPU forward control */
+#define MT7531_CFC 0x4
+#define MT7531_MIRROR_EN BIT(19)
+#define MT7531_MIRROR_MASK (MIRROR_MASK << 16)
+#define MT7531_MIRROR_PORT_GET(x) (((x) >> 16) & MIRROR_MASK)
+#define MT7531_MIRROR_PORT_SET(x) (((x) & MIRROR_MASK) << 16)
+#define MT7531_CPU_PMAP_MASK GENMASK(7, 0)
+
+#define MT753X_MIRROR_REG(id) (((id) == ID_MT7531) ? \
+ MT7531_CFC : MT7530_MFC)
+#define MT753X_MIRROR_EN(id) (((id) == ID_MT7531) ? \
+ MT7531_MIRROR_EN : MIRROR_EN)
+#define MT753X_MIRROR_MASK(id) (((id) == ID_MT7531) ? \
+ MT7531_MIRROR_MASK : MIRROR_MASK)
On Wed, 2020-08-19 at 11:49 +0800, DENG Qingfang wrote:
> Hi,
>
> Is port mirroring working? Port mirroring registers on MT7531 have
> moved, according to bpi's MT7531 reference manual.
> Please fix that as well.
On Wed, 2020-08-19 at 00:24 +0800, Vladimir Oltean wrote: > On Tue, Aug 18, 2020 at 03:14:12PM +0800, Landen Chao wrote: > > Add mt7531 dsa to bananapi-bpi-r64 board for 5 giga Ethernet ports support. > > > > Signed-off-by: Landen Chao <landen.chao@mediatek.com> > > --- > > .../dts/mediatek/mt7622-bananapi-bpi-r64.dts | 44 +++++++++++++++++++ > > 1 file changed, 44 insertions(+) > > > > diff --git a/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts b/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts > > index d174ad214857..c57b2571165f 100644 > > --- a/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts > > +++ b/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts > > @@ -143,6 +143,50 @@ > > mdio: mdio-bus { > > #address-cells = <1>; > > #size-cells = <0>; > > + > > + switch@0 { > > + compatible = "mediatek,mt7531"; > > + [snip] > > + port@6 { > > + reg = <6>; > > + label = "cpu"; > > + ethernet = <&gmac0>; > > + phy-mode = "2500base-x"; > > + }; > > Is there any reason why you're not specifying a fixed-link node here? I got the below feedback in v1, so I follow the DSA common design in v2. v2 can work with fixed-link node or without fixed-link node in CPU port node. "This fixed-link should not be needed. The DSA driver is supposed to configure the CPU port to its fastest speed by default. 2500 is the fastest speed a 2500Base-X link can do..." > > + }; > > + }; > > + > > }; > > }; > > > > -- > > 2.17.1 > > Thanks, > -Vladimir
On Wed, Aug 19, 2020 at 04:15:01PM +0800, Landen Chao wrote: > On Wed, 2020-08-19 at 00:24 +0800, Vladimir Oltean wrote: > > On Tue, Aug 18, 2020 at 03:14:12PM +0800, Landen Chao wrote: > > > Add mt7531 dsa to bananapi-bpi-r64 board for 5 giga Ethernet ports support. > > > > > > Signed-off-by: Landen Chao <landen.chao@mediatek.com> > > > --- > > > .../dts/mediatek/mt7622-bananapi-bpi-r64.dts | 44 +++++++++++++++++++ > > > 1 file changed, 44 insertions(+) > > > > > > diff --git a/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts b/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts > > > index d174ad214857..c57b2571165f 100644 > > > --- a/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts > > > +++ b/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts > > > @@ -143,6 +143,50 @@ > > > mdio: mdio-bus { > > > #address-cells = <1>; > > > #size-cells = <0>; > > > + > > > + switch@0 { > > > + compatible = "mediatek,mt7531"; > > > + > [snip] > > > + port@6 { > > > + reg = <6>; > > > + label = "cpu"; > > > + ethernet = <&gmac0>; > > > + phy-mode = "2500base-x"; > > > + }; > > > > Is there any reason why you're not specifying a fixed-link node here? > I got the below feedback in v1, so I follow the DSA common design in v2. > v2 can work with fixed-link node or without fixed-link node in CPU port > node. > > "This fixed-link should not be needed. The DSA driver is supposed to > configure the CPU port to its fastest speed by default. 2500 is > the fastest speed a 2500Base-X link can do..." See this discussion and the replies to it: https://www.spinics.net/lists/netdev/msg630102.html I think if mt7530 is using phylink for non-netdev ports (and it is), it would be good to have standard bindings that phylink can parse. For example, in lack of a "pause" specifier, will the CPU port use flow control or won't it? Why? I think there's simply no good reason why you'd omit 3 more lines now. > > > + }; > > > + }; > > > + > > > }; > > > }; > > > > > > -- > > > 2.17.1 > > > > Thanks, > > -Vladimir > -Vladimir
On Wed, 2020-08-19 at 00:09 +0800, Andrew Lunn wrote: > On Tue, Aug 18, 2020 at 03:14:10PM +0800, Landen Chao wrote: > > Add new support for MT7531: > > > > MT7531 is the next generation of MT7530. It is also a 7-ports switch with > > 5 giga embedded phys, 2 cpu ports, and the same MAC logic of MT7530. Cpu > > port 6 only supports SGMII interface. Cpu port 5 supports either RGMII > > or SGMII in different HW sku. Due to SGMII interface support, pll, and > > pad setting are different from MT7530. This patch adds different initial > > setting, and SGMII phylink handlers of MT7531. > > > > MT7531 SGMII interface can be configured in following mode: > > - 'SGMII AN mode' with in-band negotiation capability > > which is compatible with PHY_INTERFACE_MODE_SGMII. > > - 'SGMII force mode' without in-bnad negotiation > > band Sorry, I'll fix it. > > > which is compatible with 10B/8B encoding of > > PHY_INTERFACE_MODE_1000BASEX with fixed full-duplex and fixed pause. > > - 2.5 times faster clocked 'SGMII force mode' without in-bnad negotiation > > band Sorry, I'll fix it. > > > +static int mt7531_rgmii_setup(struct mt7530_priv *priv, u32 port, > > + phy_interface_t interface) > > +{ > > + u32 val; > > + > > + if (!mt7531_is_rgmii_port(priv, port)) { > > + dev_err(priv->dev, "RGMII mode is not available for port %d\n", > > + port); > > + return -EINVAL; > > + } > > + > > + val = mt7530_read(priv, MT7531_CLKGEN_CTRL); > > + val |= GP_CLK_EN; > > + val &= ~GP_MODE_MASK; > > + val |= GP_MODE(MT7531_GP_MODE_RGMII); > > + val &= ~(TXCLK_NO_REVERSE | RXCLK_NO_DELAY); > > + switch (interface) { > > + case PHY_INTERFACE_MODE_RGMII: > > + val |= TXCLK_NO_REVERSE; > > + val |= RXCLK_NO_DELAY; > > + break; > > + case PHY_INTERFACE_MODE_RGMII_RXID: > > + val |= TXCLK_NO_REVERSE; > > + break; > > + case PHY_INTERFACE_MODE_RGMII_TXID: > > + val |= RXCLK_NO_DELAY; > > + break; > > + case PHY_INTERFACE_MODE_RGMII_ID: > > + break; > > + default: > > + return -EINVAL; > > + } > > You need to be careful here. If the MAC is doing the RGMII delays, you > need to ensure the PHY is not. What interface mode is passed to the > PHY? Hi Andrew, mt7531 RGMII port is a MAC-only port, it can be connected to CPU MAC or external phy. In bpi-r64 board, mt7531 RGMII is connected to CPU MAC, so I tend to implement RGMII logic for use case of bpi-r64. In general, according to phy.rst, RGMII delay should be done by phy, but some MoCA product need RGMII delay in MAC. These two requirements conflict. Is there any suggestion to solve the conflict? If mt7531 RGMII implementation needs to satisfy either phy.rst or special MoCA product, I would like to satisfy phy.rst and remove MAC RGMII delay in v3. For special product needs MAC RGMII delay, this patch can be used in its local codebase. Landen > > Andrew
Hi Jakub, These 2 function are used in the same file only. I'll fix warnings by making 2 functions 'static' in v3. Landen On Tue, 2020-08-18 at 23:23 +0800, Jakub Kicinski wrote: [snip] > Please fix these W=1 warnings: > > ../drivers/net/dsa/mt7530.c:1976:1: warning: no previous prototype for ‘mt7531_sgmii_link_up_force’ [-Wmissing-prototypes] > 1976 | mt7531_sgmii_link_up_force(struct dsa_switch *ds, int port, > | ^~~~~~~~~~~~~~~~~~~~~~~~~~ > ../drivers/net/dsa/mt7530.c:2081:6: warning: no previous prototype for ‘mt7531_sgmii_restart_an’ [-Wmissing-prototypes] > 2081 | void mt7531_sgmii_restart_an(struct dsa_switch *ds, int port) > | ^~~~~~~~~~~~~~~~~~~~~~~ > ../drivers/net/dsa/mt7530.c:1976:1: warning: symbol 'mt7531_sgmii_link_up_force' was not declared. Should it be static? > ../drivers/net/dsa/mt7530.c:2081:6: warning: symbol 'mt7531_sgmii_restart_an' was not declared. Should it be static?
> In general, according to phy.rst, RGMII delay should be done by phy, but > some MoCA product need RGMII delay in MAC. These two requirements > conflict. Is there any suggestion to solve the conflict? Implementing the delay in the PHY is just a recommendation, not a requirement. However, as i said, you need to be careful what is pass to phylib. If the MAC is implementing "rgmii-id", whatever makes it way down to phy_attach_direct() needs to be "rgmii". If the MAC implements "rgmii-rxid", the phy should be implementing "rgmii-txid", etc. If this is wrong, you get both the MAC and the PHY implementing delays, and bad things happen. Andrew
Quoting Landen Chao <landen.chao@mediatek.com>: > On Wed, 2020-08-19 at 00:09 +0800, Andrew Lunn wrote: >> On Tue, Aug 18, 2020 at 03:14:10PM +0800, Landen Chao wrote: >> > Add new support for MT7531: >> > >> > MT7531 is the next generation of MT7530. It is also a 7-ports switch with >> > 5 giga embedded phys, 2 cpu ports, and the same MAC logic of MT7530. Cpu >> > port 6 only supports SGMII interface. Cpu port 5 supports either RGMII >> > or SGMII in different HW sku. Due to SGMII interface support, pll, and >> > pad setting are different from MT7530. This patch adds different initial >> > setting, and SGMII phylink handlers of MT7531. >> > >> > MT7531 SGMII interface can be configured in following mode: >> > - 'SGMII AN mode' with in-band negotiation capability >> > which is compatible with PHY_INTERFACE_MODE_SGMII. >> > - 'SGMII force mode' without in-bnad negotiation >> >> band > Sorry, I'll fix it. >> >> > which is compatible with 10B/8B encoding of >> > PHY_INTERFACE_MODE_1000BASEX with fixed full-duplex and fixed pause. >> > - 2.5 times faster clocked 'SGMII force mode' without in-bnad negotiation >> >> band > Sorry, I'll fix it. >> >> > +static int mt7531_rgmii_setup(struct mt7530_priv *priv, u32 port, >> > + phy_interface_t interface) >> > +{ >> > + u32 val; >> > + >> > + if (!mt7531_is_rgmii_port(priv, port)) { >> > + dev_err(priv->dev, "RGMII mode is not available for port %d\n", >> > + port); >> > + return -EINVAL; >> > + } >> > + >> > + val = mt7530_read(priv, MT7531_CLKGEN_CTRL); >> > + val |= GP_CLK_EN; >> > + val &= ~GP_MODE_MASK; >> > + val |= GP_MODE(MT7531_GP_MODE_RGMII); >> > + val &= ~(TXCLK_NO_REVERSE | RXCLK_NO_DELAY); >> > + switch (interface) { >> > + case PHY_INTERFACE_MODE_RGMII: >> > + val |= TXCLK_NO_REVERSE; >> > + val |= RXCLK_NO_DELAY; >> > + break; >> > + case PHY_INTERFACE_MODE_RGMII_RXID: >> > + val |= TXCLK_NO_REVERSE; >> > + break; >> > + case PHY_INTERFACE_MODE_RGMII_TXID: >> > + val |= RXCLK_NO_DELAY; >> > + break; >> > + case PHY_INTERFACE_MODE_RGMII_ID: >> > + break; >> > + default: >> > + return -EINVAL; >> > + } >> >> You need to be careful here. If the MAC is doing the RGMII delays, you >> need to ensure the PHY is not. What interface mode is passed to the >> PHY? > Hi Andrew, > > mt7531 RGMII port is a MAC-only port, it can be connected to CPU MAC or > external phy. In bpi-r64 board, mt7531 RGMII is connected to CPU MAC, so > I tend to implement RGMII logic for use case of bpi-r64. > > In general, according to phy.rst, RGMII delay should be done by phy, but > some MoCA product need RGMII delay in MAC. These two requirements > conflict. Is there any suggestion to solve the conflict? > > If mt7531 RGMII implementation needs to satisfy either phy.rst or > special MoCA product, I would like to satisfy phy.rst and remove MAC > RGMII delay in v3. For special product needs MAC RGMII delay, this patch > can be used in its local codebase. Hi Landen, With the current mainline code [1], the dsa code tries to detect how the MAC5 is used. All the three modes are supported. MAC5 -> PHY0, MAC5 -> PHY4, MAC5 -> EXTERNAL PHY and MAC5 to external MAC. When MAC5 is a DSA port it skips settings the delay settings. See [2]. Maybe you can use a similar concept. Greats, René [1] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/drivers/net/dsa/mt7530.c#n1303 [2] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/drivers/net/dsa/mt7530.c#n598 > > Landen >> >> Andrew
Hi! On Thu, Aug 20, 2020 at 7:55 AM René van Dorst <opensource@vdorst.com> wrote: > > With the current mainline code [1], the dsa code tries to detect how the MAC5 > is used. All the three modes are supported. MAC5 -> PHY0, MAC5 -> > PHY4, MAC5 -> > EXTERNAL PHY and MAC5 to external MAC. > > When MAC5 is a DSA port it skips settings the delay settings. See [2]. > > Maybe you can use a similar concept. Current detection relies on an incorrect assumption that mt753x switch is always used with mtk_eth_soc. It's a really hacky solution to use dt properties that don't belong to this switch at all and I think this approach should not be followed further by future code. The usage of mac5 should be explicitly defined as a dt property under mt753x node.
This patch series adds support for MT7531. MT7531 is the next generation of MT7530 which could be found on Mediatek router platforms such as MT7622 or MT7629. It is also a 7-ports switch with 5 giga embedded phys, 2 cpu ports, and the same MAC logic of MT7530. Cpu port 6 only supports SGMII interface. Cpu port 5 supports either RGMII or SGMII in different HW SKU. Due to support for SGMII interface, pll, and pad setting are different from MT7530. MT7531 SGMII interface can be configured in following mode: - 'SGMII AN mode' with in-band negotiation capability which is compatible with PHY_INTERFACE_MODE_SGMII. - 'SGMII force mode' without in-bnad negotiation which is compatible with 10B/8B encoding of PHY_INTERFACE_MODE_1000BASEX with fixed full-duplex and fixed pause. - 2.5 times faster clocked 'SGMII force mode' without in-bnad negotiation which is compatible with 10B/8B encoding of PHY_INTERFACE_MODE_2500BASEX with fixed full-duplex and fixed pause. changes between v1 & v2 - change phylink_validate callback function to support full-duplex gigabit only to match hardware capability. - add description of SGMII interface. - configure mt7531 cpu port in fastest speed by default. - parse SGMII control word for in-band negotiation mode. - configure RGMII delay based on phy.rst. - Rename the definition in the header file to avoid potential conflicts. - Add wrapper function for mdio read/write to support both C22 and C45. - correct fixed-link speed of 2500base-x in dts. - add MT7531 port mirror setting. Landen Chao (7): net: dsa: mt7530: Refine message in Kconfig net: dsa: mt7530: support full-duplex gigabit only net: dsa: mt7530: Extend device data ready for adding a new hardware dt-bindings: net: dsa: add new MT7531 binding to support MT7531 net: dsa: mt7530: Add the support of MT7531 switch arm64: dts: mt7622: add mt7531 dsa to mt7622-rfb1 board arm64: dts: mt7622: add mt7531 dsa to bananapi-bpi-r64 board .../devicetree/bindings/net/dsa/mt7530.txt | 71 +- .../dts/mediatek/mt7622-bananapi-bpi-r64.dts | 44 + arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts | 57 +- drivers/net/dsa/Kconfig | 6 +- drivers/net/dsa/mt7530.c | 1184 +++++++++++++++-- drivers/net/dsa/mt7530.h | 259 +++- 6 files changed, 1514 insertions(+), 107 deletions(-)