public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
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.

      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