mocrochip ksz8795 switch on LS1012a

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

mocrochip ksz8795 switch on LS1012a

861件の閲覧回数
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 返答(返信)

815件の閲覧回数
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 件の賞賛

830件の閲覧回数
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 件の賞賛