Hi Tristram,

Thanks for your feedback.

What is the behavior when the reserved multicast table is not enabled
(does it forward to all ports, drop all mcast, something else?)

quoted

The default reserved multicast table forwards to host port on entries 0,
2, and 6; skips host port on entries 4, 5, and 7; forwards to all ports
on entry 3; and drops on entry 1.

Is this behavior the desired behavior as far as the Linux DSA folks would want?

commit 331d64f752bb ("net: dsa: microchip: add the enable_stp_addr
pointer in ksz_dev_ops") enables the reserved multicast table and
adjusts the cpu port for entry 0 leaving the rest the same (and wrong
if the cpu port is not the highest port in the switch).

My patch adjusts the entries but keeps the rules the same and the
question that is posed is that the right thing to do with respect to
Linux DSA?

When reserved multicast address table is not enabled the multicast
forwarding follows the standard operation which is broadcast to all
ports.

Note KSZ9477 and LAN937X are able to program multicast forwarding in
either static or dynamic MAC table with high entry count, so it is
probably best to not use the reserved multicast address table and let the
DSA stack program each multicast address individually.