mocrochip ksz8795 switch on LS1012a

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

mocrochip ksz8795 switch on LS1012a

1,692 Views
reginaldstjohn
Contributor III

We have a custom board using a Layerscape ls1012a processor hooked up in the following manner.

 

WAPII_EnetConnections.gif

We are building openwrt with a 5.4 kernel that has divers for both chips. However, we are struggling to get our device tree configured so that either chip is probed correctly. We believe our RCW is configured correctly but we get a MDIO "device at address 0 is missing" when probing the MDIO bus and we get an error -22 (bad parameter) for the SPI switch.

We have tracked the SPI switch error to it not finding the phy-mode node even though we have it in several places.

Below are the relevent parts of our device tree.

&pfe {
      	status = "okay";
        #address-cells = <1>;
        #size-cells = <0>;

        pfe_mac0: ethernet@0 {
                compatible = "fsl,pfe-gemac-port";
                #address-cells = <1>;
                #size-cells = <0>;
                reg = <0x0>;    /* GEM_ID */
                fsl,mdio-mux-val = <0x0>;
                phy-mode = "sgmii";
                phy-handle = <&wan_phy>;
        };

	pfe_mac1: ethernet@1 {
                phy-mode = "rgmii";
                #address-cells = <1>;
                #size-cells = <0>;
                reg = <0x1>;
                fixed-link {
                        speed = <1000>;
                        full-duplex;
                };
        };
	mdio@0 {
                #address-cells = <1>;
                #size-cells = <0>;

                wan_phy: ethernet-phy@0 {
                        reg = <0x0>; /* Phy Address on mdio bus */
                        //phy-mode = "sgmii";
                        tx-fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
                };
        };
};
&dspi {
       	status = "okay";

        ksz8794: ksz8794@0 {
                status = "okay";
                compatible = "microchip,ksz8794";
                reg = <0>;

                spi-max-frequency = <10000000>;
                spi-cpha;
                spi-cpol;

                ports {
                        #address-cells = <1>;
                        #size-cells = <0>;
                        port@0 {
                                reg = <0>;
                                label = "lan1";
                        };
                        port@1 {
                                reg = <1>;
                                label = "lan2";
                        };
                        port@2 {
                                reg = <2>;
                                label = "lan3";
                        };
                        port@3 {
                                reg = <4>;
                                label = "cpu";
                                ethernet = <&pfe_mac1>;
                                phy-mode = "rgmii";
                                fixed-link {
                                        speed = <1000>;
                                        full-duplex;
                                };
                        };
                };
        };
};

 

Any help or direction would be appreciated. 

0 Kudos
Reply
2 Replies

1,646 Views
reginaldstjohn
Contributor III

We have found that the problem is that the driver is written to not expect more then 3 ports even though the documentation clearly states that we should have our device tree as above. It seems that in our codebase, Openwrt, the driver is not written correctly.  It seems, to us, that the driver was never tested or was written for a different device tree.

In the mainline Linux Kernel there are patches trying to fix issues similar to ours. We will have to look at backporting a driver to our kernel version, 5.10 I believe, or upgrading our distribution to see if the fixes have been applied.

0 Kudos
Reply

1,661 Views
bpe
NXP Employee
NXP Employee

I do not see anything wrong in the DT declaration of the PHY connected directly
to SGMII/pfe_mac0. The diagnostic message you are seeing tells that the kernel
actually attempts to find the PHY where the DT instructs it to. The error
appears most likely because the driver does not get the expected response from
the PHY.

As of the switch and it's driver, it is not an NXP product. We do not have
expertise in this device and cannot advice on configuring and using it, sorry.
Our suggestion in this regard is to approach the switch vendor for support.

Best Regards,
Platon

 

0 Kudos
Reply