mocrochip ksz8795 switch on LS1012a

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

mocrochip ksz8795 switch on LS1012a

1,121 次查看
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 项奖励
2 回复数

1,075 次查看
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 项奖励

1,090 次查看
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 项奖励