From: "Joris Vaišvila" <joey@tinyisr.com>
To: Daniel Golle <daniel@makrotopia.org>
Cc: netdev@vger.kernel.org, horms@kernel.org, pabeni@redhat.com,
kuba@kernel.org, edumazet@google.com, davem@davemloft.net,
olteanv@gmail.com, Andrew Lunn <andrew@lunn.ch>
Subject: Re: [RFC v2 3/3] net: dsa: initial support for MT7628 embedded switch
Date: Sun, 15 Mar 2026 09:02:25 +0200 [thread overview]
Message-ID: <abZTnRlDRFl2deFY@archlinux> (raw)
In-Reply-To: <abXyKK4wxiBySHI2@makrotopia.org>
On Sat, Mar 14, 2026 at 11:41:28PM +0000, Daniel Golle wrote:
> > The switch has 5 built-in 100Mbps ports (ports 0-4) and 2x 1Gbps ports.
> > One of the 1Gbps ports (port 6) is internally attached to the SoCs CPU
> > MAC and serves as the CPU port. The other 1Gbps port (port 5) requires
> > an external MAC to function.
>
> I thought port 5 is a dead-end on MT76x8. Afaik it was only used on
> Ralink Rt3052 for RGMII/xMII with this switch IP, and not wired to
> any external pins nor to an internal MAC on all other SoCs which came
> after.
I assumed this was true as that's what the datasheet says, but looking
at the pinout it really doesn't have any pins to attach an external mac.
> > + This enables support for the switch in the MT7628 SoC.
>
> And potentially many others (Rt3052, Rt3050, Rt3352, Rt5350).
> As support for the Rt5350 is present in mtk_eth_soc at least that
> sounds like it would be worth mentioning (or even naming the driver
> and tagger interely after rt3050 which is the origin of that IP
> block).
The RT3050 does not support all the same features the RT5350 does (which
I believe the MT7628 is based on). The DSA tag is now set up in a way
that only the MT7628 and potentially RT5350 can support. The DSA tag
does not appear to be working as described in the datasheet on these
switches and I do not have any of the ralink switches to test this on.
I don't think it's a good idea to assert support for hardware that has
not been tested with this.
I thought it would be fitting for the driver to be called after the
MT7628 as that would be the first supported SoC and add support for the
ralink switches later.
> > [...]
> > +static void mt7628_phylink_get_caps(struct dsa_switch *ds, int port,
> > + struct phylink_config *config)
> > +{
> > + config->mac_capabilities = MAC_100 | MAC_10;
> > + __set_bit(PHY_INTERFACE_MODE_MII, config->supported_interfaces);
> > + __set_bit(PHY_INTERFACE_MODE_GMII, config->supported_interfaces);
>
> This looks a bit wrong.
> Aren't all 5 PHYs internal? PHY_INTERFACE_INTERNAL would be best to
> describe them then. And doesn't the CPU port (6) connect with 1000M,
> if so it should have MAC_1000 set as well (as neither the Ethernet
> driver nor the DSA driver do anything to configure the interface that
> is purely cosmetic, but still)
Will fix this and coding style issues in v3.
> Iff you want to support port 5 on Rt3052 (which will also require
> setting the correct interface mode in .mac_config) I'd expect something
> like this:
>
> config->mac_capabilities = MAC_100 | MAC_10;
>
> switch (port) {
> case 0...4:
> __set_bit(PHY_INTERFACE_INTERNAL, config->supported_interfaces);
> break;
> case 5:
> __set_bit(PHY_INTERFACE_MODE_MII, config->supported_interfaces);
> __set_bit(PHY_INTERFACE_MODE_REVMII, config->supported_interfaces);
> __set_bit(PHY_INTERFACE_MODE_RMII, config->supported_interfaces);
> __set_bit(PHY_INTERFACE_MODE_RGMII, config->supported_interfaces);
> config->mac_capabilities |= MAC_1000;
> break;
> case 6:
> __set_bit(PHY_INTERFACE_INTERNAL, config->supported_interfaces);
> config->mac_capabilities |= MAC_1000;
> break;
> default:
> return;
> }
>
> If you don't want to deal with port 5 you should skip it here as well.
Will skip port 5 for now, due to this driver likely not working on
RT3052 as it is anyway for the aforementioned reasons.
Thanks for the review.
prev parent reply other threads:[~2026-03-15 7:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-14 15:08 [RFC v2 0/3] net: dsa: MT7628 embedded switch initial support Joris Vaisvila
2026-03-14 15:08 ` [RFC v2 1/3] net: phy: mediatek: add phy driver for MT7628 built-in Fast Ethernet PHYs Joris Vaisvila
2026-03-17 18:03 ` Andrew Lunn
2026-03-21 11:35 ` Joris Vaisvila
2026-03-14 15:08 ` [RFC v2 2/3] net: dsa: initial MT7628 tagging driver Joris Vaisvila
2026-03-14 17:59 ` Daniel Golle
2026-03-14 20:46 ` Joris Vaišvila
2026-03-14 15:08 ` [RFC v2 3/3] net: dsa: initial support for MT7628 embedded switch Joris Vaisvila
2026-03-14 23:41 ` Daniel Golle
2026-03-15 7:02 ` Joris Vaišvila [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=abZTnRlDRFl2deFY@archlinux \
--to=joey@tinyisr.com \
--cc=andrew@lunn.ch \
--cc=daniel@makrotopia.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox