Re: [PATCH net-next v4 3/3] net: dsa: qca8k: support QCA8337 internal PHY CPU links

[Yongzhao Chen]

Hi Christian,

Thanks for the review.

> Can you put an example DT for this? Also no additional register are needed
> to this special mode?

Here is an example using the switch's internal MDIO bus, with the other
user ports omitted. The SoC MAC has its own PHY at the other end of the
PHY-to-PHY connection; its phy-mode must follow that MAC's binding. The
full example passed dtc and the qca8k binding check.

    switch@10 {
        compatible = "qca,qca8337";
        reg = <0x10>;

        ports {
            #address-cells = <1>;
            #size-cells = <0>;

            port@1 {
                reg = <1>;
                label = "lan1";
                phy-mode = "internal";
                phy-handle = <&switch_phy0>;
            };

            port@5 {
                reg = <5>;
                ethernet = <&soc_mac>;
                phy-mode = "internal";
                phy-handle = <&switch_phy4>;
            };
        };

        mdio {
            #address-cells = <1>;
            #size-cells = <0>;
            switch_phy0: ethernet-phy@0 { reg = <0>; };
            switch_phy4: ethernet-phy@4 { reg = <4>; };
        };
    };

I did not add any register writes for this mode: qca8k_setup() already
programs header mode for the CPU port, the four GLOBAL_FW_CTRL1
destination masks, and the CPU/user membership masks using the selected
port. CPU_PORT_EN remains set by the existing setup code; I have not
tested clearing it.

I tested port 5 as the only CPU port on a Redmi AX5400 (RA74) with an
OpenWrt Linux 6.18.52 backport. Readback showed header mode only on
port 5 and all four destination masks selecting port 5. BPDU, LLDP,
EAPOL-Start and broadcast ARP frames arrived intact in both directions,
and unknown unicast/multicast flooding toward the CPU, DHCP, MTU
changes, renegotiation and ping also passed.

That test used the external MDIO bus with wireless disabled, and needed
two workarounds that are not in the posted series: a dummy phy-handle on
port 6 (a fixed-link user port) for MDIO classification, and a NULL-PHY
guard in qca8k_port_enable(). So it does not validate the internal-MDIO
example above on hardware. I will reword the commit message in the next
revision to claim only what was tested.

Would you prefer the fixed-link NULL-PHY handling to be addressed in a
separate prerequisite patch? The guard skips phy_support_asym_pause()
when phy is NULL, as it is for a fixed-link user port. For port 5, are
there other CPU-port registers or traffic paths you would want checked,
or is testing the internal-MDIO configuration on hardware the main gap?

Thanks,
Yongzhao Chen