Debugging EcoNet's MT7530 PHYs

[Caleb James DeLisle]

On 11/02/2026 11:26, Daniel Golle wrote:
> On Wed, Feb 11, 2026 at 11:13:26AM +0100, Caleb James DeLisle wrote:
>> On 10/02/2026 23:12, Benjamin Larsson wrote:
>>> If I understand correct, the ref SDK just sets up a transparent bridge
>>> and lets the packets flow through? If that is correct is that an option
>>> here?
>> When use_soc_lan is unset, this is what happens. When use_soc_lan is set, it
>> does a bunch of highly awkward stuff to add support for one extra port on
>> the internal switch. It's an option, probably to treat the internal switch
>> as part of the eth driver - however this will not work on EN7526C which no
>> external switch, internal is exposed.
>>> And IMO we should not stack stags. If it is possible to pass stags
>>> through with the pass-through bit intact it should be possible to
>>> address all ports on both switches with just one stag.
>>>
>>> I was hoping the PT_OPTION PVC bit would set the stag pass through bit
>>> on incoming frames.
>> Stacking stags does potentially have a performance penalty in the tag parser
>> - I say "potentially" because it's already walking a list which could be an
>> array index, and even 2 array indexes is faster than what we have now.
>>
>> But trying to use the PT bit as designed makes it impossible to
>> differentiate between a packet that came from port N of the external switch
>> and a packet that came from port N of the internal. Vendor code doesn't
>> support having the same port number active on both internal and external, if
>> you try it will quietly overwrite the switch_port_map entry in
>> init_ethernet_port_map(), so I surmise this is a real silicon bug, not a
>> misconfiguration on my end.
>>
>> But (so far), stacking tags seems to work, so I would much prefer it to
>> inter-switch rules, i.e. "you can't enable this port in the DT because you
>> have one with the same number on the other switch".
>>
> So if the vendor SDK doesn't allow using the same port number on both,
> the on-die and the MCM switch, that means there won't be any boards
> around doing that, right? Nobody is designing new boards with this
> silicon at this point, all existing boards had to adhere to those rules.
> Hence I don't see why the extra overhead of stacked special tags would
> be worth it, especially also given that stacked special tags also won't
> work with the hardware offloading PPE/HWNAT, and likely also break other
> stuff such as TX checksum offloading.
>
>> BTW Vendor code (see: TCSUPPORT_MULTI_SWITCH_EXT) suggests there are boards
>> with multiple external switches. Probably a board integrator hung another
>> 7530 off of one of the RGMII interfaces. Per my reading, vendor code falls
>> back on VLANs, giving up on the stag entirely. I haven't confirmed that
>> transmit works yet, but assuming it does, stacked stags should Just Work in
>> this use case whereas the PT bit clearly would not.
> Have you seen any boards actually using an additional (ie. third) MT7530
> connected as external IC? If this feature is only a theoretical option
> which none of the board markers choose to implement I think it's worth
> ignoring it and not supporting it upstream, especially if the vendor SDK
> just uses the swconfig driver with VLANs rather than DSA.


Okay, I'll put a "no port reuse" check in mt7530.c and in tag_mtk.c I'll 
just the dsa_conduit_find_user() with a relaxed walker that ignores 
switch ID, then make mtk_tag_xmit() set the PT bit if switch ID is 
non-zero. Chaining will support 1 downstream switch on port 5, and any 
port used on one switch cannot be used on the other.


Thanks,

Caleb