Re: [PATCH v3 2/7] dt-bindings: net: dsa: mediatek,mt7530: add passthrough mode

On 28/10/2026 13:28, Andrew Lunn wrote:

On Wed, Oct 28, 2026 at 12:27:18PM +0100, Caleb James DeLisle wrote:

quoted

On 28/10/2026 03:04, Andrew Lunn wrote:

quoted

On Wed, Oct 28, 2026 at 01:13:12AM +0000, Caleb James DeLisle wrote:

quoted

MT7530 switches can be configured to blindly pass packets between their
CPU/upstream port and a downstream DSA port, in particular, without
altering the MediaTek DSA Tag on the packets. This mode is used in some
integrations where an SoC integrated switch exists, but a more capable
MCM switch is added to effectively replace it.

Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
---
   .../devicetree/bindings/net/dsa/mediatek,mt7530.yaml       | 7 +++++++
   1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
index 90b3582b7619..e29fb8693498 100644
--- a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml

@@ -73,6 +73,13 @@ description: |
         Check out example 7.
+  The MT7530 and MT7531 switches are capable of being operated in "passthrough"
+  mode. In this mode, traffic is unconditionally passed between the CPU port
+  and the DSA port which links to a second switch. To use passthrough mode, the
+  upstream switch is configured with a DSA link to the downstream switch. In
+  passthrough mode the upstream switch is restricted, with no other ports or
+  switch configuration allowed.
+
   properties:
     compatible:
       oneOf:

Looking at just what is here, all i see is a comment. There is no new
property? Yet the subject is "add passthrough mode"?

Indeed, I used "add" to mean "add documentation of". Per my reply on patch
3, I think we really prefer to avoid special properties and let this
constitute (very) limited support for a switch hierarchy.

If there's another verb you think makes a better commit line, I'd be happy
to adjust.

[Goes and looks at mediatek,mt7530.yaml]

So pass through is not an existing property. You are also not adding a
new property 'passthrough'.

What you appear to be saying is that the MT7530 and MT7531 are hard
coded by the driver into pass through mode? So it is in effect a
property of the compatible? So maybe put this comment next to the
compatible? And make the subject/commit message talk about the
compatible being hard coded for pass through?

Perhaps I should rephrase as follows:


"""

The MT7530 and MT7531 switches do not support switch hierarchies except in
the case that a switch is configured with only one CPU port and one DSA port
that links to a downstream switch. In this configuration, the upstream switch
acts as a blind pass-through to the downstream switch.
"""

Looking forward, what happens when somebody wants to use the switch as
a switch? Or you figure out how to do proper D in DSA? It becomes
messy because you need to add a property indicating the compatible
should actually be a switch?

Full hierarchy (using DSA tag) is impossible because of what seems to be a hardware bug where switches don't distinguish themselves in the tag. However it is possible (albeit ugly) to enable ports on both switches providing the same numbered port isn't enabled on both switches.


If somebody ever implements that, even if they remove this passthrough support, users of the current passthrough capability will not notice a difference because that will do the same as this.

So maybe you really do need a property?

But DT describes hardware, and pass through is configuration. So maybe
it should not be in DT at all, Maybe the driver needs to look at the
DT tree, figure out a port is used as a DSA port, and put the switch
into pass through all on its own? Once D in DSA is supported, the
addition ports become available, but no other changes are needed in
the DT blob?

Previously there was no documentation regarding hierarchies, and any hierarchy would fail at runtime. I think a brief note that this one case of hierarchy is allowed is nice for the users, though it does bend the definition of "describing the hardware" so it could also be excluded. I may be persuaded either way.


Thanks,

Caleb

Sorry, going around in circles, but hopefully it helps you think about
the big picture.

	   Andrew