Microchip-Ethernet / EVB-KSZ9477

Repository for using Microchip EVB-KSZ9477 board. Product Supported: KSZ9477, KSZ9567, KSZ9897, KSZ9896, KSZ8567, KSZ8565, KSZ9893, KSZ9563, KSZ8563, LAN9646, Phys(KSZ9031/9131, LAN8770
76 stars 79 forks source link

Pings don't go after Microchip KSZ driver loading. (All works before it has been loaded.) #68

Closed nevapadonak closed 3 years ago

nevapadonak commented 3 years ago

Hello!

I use EVB-KSZ9477/KSZ/kernels/linux-4.9.143/drivers/net/dsa/microchip/ksz8863_spi.c driver.

The problem is the packets don't go through Ethernet interfaces. I have development board with KSZ8895 switch and PC. The PC is connected to lan2@eth0 virtual interface of KSZ8895 switch.

I did ping from CPU port eth0 on development board to PC. The PC sees incoming ARP packet, sends ARP response back, but then the board sends a new ARP request, so it didn't receive any packets.

This is part of my DTS:

&ecspi4 {
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_ecspi4>;
    fsl,spi-num-chipselects = <2>;
    cs-gpios = <&gpio2 15 GPIO_ACTIVE_LOW>,
               <&gpio2 10 GPIO_ACTIVE_LOW>;
    status = "okay";
    #address-cells = <1>;
    #size-cells = <0>;

    ksz8895: spi@0 {
        compatible = "microchip,ksz8895";
        reg = <0x00>;
        phy-mode = "rmii";
        //spi-max-frequency = <25000000>; // According to datashit, but it doesn't work =(
        spi-max-frequency = <10000000>;
        ports {
            #address-cells = <1>;
            #size-cells = <0>;
            port@0 {
                reg = <0>;
                label = "cpu";
                ethernet = <&fec1>;
            };
            port@1 {
                reg = <1>;
                label = "lan1";
            };
            port@2 {
                reg = <2>;
                label = "lan2";
            };
            port@3 {
                reg = <3>;
                label = "lan3";
            };
            port@4 {
                reg = <4>;
                label = "wifi";
            };
        };
    };
};

&fec1 {
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_enet1>;
    phy-mode = "rmii";
    phy-reset-gpios = <&gpio5 1 0>;
    phy-handle = <&ethphy0>;
    fsl,magic-packet;
    status = "okay";
    max-speed = <100>;
    mdio {
        #address-cells = <1>;
        #size-cells = <0>;
        ethphy0: ethernet-phy@0 {
            compatible = "ethernet-phy-ieee802.3-c22";
            reg = <0>;
            smsc,disable-energy-detect;
        };
    };
};

The ip link output:

root@OpenWrt-korda:/tmp# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000
    link/ether 52:54:1b:1f:6c:08 brd ff:ff:ff:ff:ff:ff
3: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN qlen 1000
    link/gre 0.0.0.0 brd 0.0.0.0
4: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
5: erspan0@NONE: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
6: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
    link/ether 52:54:1b:1f:6c:08 brd ff:ff:ff:ff:ff:ff
7: lan2@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
    link/ether 52:54:1b:1f:6c:08 brd ff:ff:ff:ff:ff:ff
8: lan3@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN qlen 1000
    link/ether 52:54:1b:1f:6c:08 brd ff:ff:ff:ff:ff:ff
9: wifi@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether 52:54:1b:1f:6c:08 brd ff:ff:ff:ff:ff:ff
10: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN qlen 1000
    link/tunnel6 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 brd 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
11: ip6gre0@NONE: <NOARP> mtu 1448 qdisc noop state DOWN qlen 1000
    link/[823] 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 brd 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
13: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 52:54:4a:43:65:08 brd ff:ff:ff:ff:ff:ff

We see the driver created virtual lan1-lan3 interfaces. The KSZ driver loading debug:

root@OpenWrt-korda:/tmp# dmesg | grep 8895
[    1.379570] bus: 'spi': add driver ksz8895-switch
[    1.379641] bus: 'spi': driver_probe_device: matched device spi3.0 with driver ksz8895-switch
[    1.379666] bus: 'spi': really_probe: probing driver ksz8895-switch with device spi3.0
[    1.379718] ksz8895-switch spi3.0: no pinctrl handle
[    1.382409] bus: 'mdio_bus': add driver Microchip KSZ8895 Switch
[    1.382930] bus: 'mdio_bus': remove driver Microchip KSZ8895 Switch
[    1.383485] driver: 'Microchip KSZ8895 Switch': driver_release
[    2.181484] bus: 'mdio_bus': add driver Microchip KSZ8895 Switch
[    2.370361] bus: 'mdio_bus': driver_probe_device: matched device dsa-0.0:01 with driver Microchip KSZ8895 Switch
[    2.370380] bus: 'mdio_bus': really_probe: probing driver Microchip KSZ8895 Switch with device dsa-0.0:01
[    2.370427] Microchip KSZ8895 Switch dsa-0.0:01: no default pinctrl state
[    2.370470] driver: 'Microchip KSZ8895 Switch': driver_bound: bound to device 'dsa-0.0:01'
[    2.370688] bus: 'mdio_bus': really_probe: bound device dsa-0.0:01 to driver Microchip KSZ8895 Switch
[    2.371758] bus: 'mdio_bus': driver_probe_device: matched device dsa-0.0:02 with driver Microchip KSZ8895 Switch
[    2.371777] bus: 'mdio_bus': really_probe: probing driver Microchip KSZ8895 Switch with device dsa-0.0:02
[    2.371818] Microchip KSZ8895 Switch dsa-0.0:02: no default pinctrl state
[    2.371859] driver: 'Microchip KSZ8895 Switch': driver_bound: bound to device 'dsa-0.0:02'
[    2.372067] bus: 'mdio_bus': really_probe: bound device dsa-0.0:02 to driver Microchip KSZ8895 Switch
[    2.373143[  112.412740] watchdog: watchdog0: watchdog did not stop!
] bus: 'mdio_bus': driver_probe_device: matched device dsa-0.0:03 with driver Microchip KSZ8895 Switch
[    2.373487] bus: 'mdio_bus': really_probe: probing driver Microchip KSZ8895 Switch with device dsa-0.0:03
[    2.373532] Microchip KSZ8895 Switch dsa-0.0:03: no default pinctrl state
[    2.373576] driver: 'Microchip KSZ8895 Switch': driver_bound: bound to device 'dsa-0.0:03'
[    2.373778] bus: 'mdio_bus': really_probe: bound device dsa-0.0:03 to driver Microchip KSZ8895 Switch
[    2.374869] bus: 'mdio_bus': driver_probe_device: matched device dsa-0.0:04 with driver Microchip KSZ8895 Switch
[    2.374886] bus: 'mdio_bus': really_probe: probing driver Microchip KSZ8895 Switch with device dsa-0.0:04
[    2.374925] Microchip KSZ8895 Switch dsa-0.0:04: no default pinctrl state
[    2.374961] driver: 'Microchip KSZ8895 Switch': driver_bound: bound to device 'dsa-0.0:04'
[    2.375006] bus: 'mdio_bus': really_probe: bound device dsa-0.0:04 to driver Microchip KSZ8895 Switch
[    2.380683] itch spi3.0 lan1 (uninitialized): PHY [dsa-0.0:01] driver [Microchip KSZ8895 Switch]
[    2.391909] itch spi3.0 lan2 (uninitialized): PHY [dsa-0.0:02] driver [Microchip KSZ8895 Switch]
[    2.403766] itch spi3.0 lan3 (uninitialized): PHY [dsa-0.0:03] driver [Microchip KSZ8895 Switch]
[    2.415076] itch spi3.0 wifi (uninitialized): PHY [dsa-0.0:04] driver [Microchip KSZ8895 Switch]

Can you help me or give me some advice?

The pings go successfully before ksz8895 driver is loaded. So the driver breaks the network. I think uninitialized status of virtual lan1-lan3 ports may means somewhat? How to fix them to be initialized?

Thanks. Artem Korotchenko.

triha2work commented 3 years ago

The last port in the switch is the host port that connects to the MAC. The DSA driver uses tail tagging which means only the last port will work. The device tree defines the first port as the CPU port.

nevapadonak commented 3 years ago

The last port in the switch is the host port that connects to the MAC. The DSA driver uses tail tagging which means only the last port will work. The device tree defines the first port as the CPU port.

Thank you! Is it possible to fix driver to support first port as CPU and not last?

nevapadonak commented 3 years ago

The problem is solved! CPU port should only be wired to KSZ8895 switch as 5 (last) port. It is hardware requierment, not the driver restriction.