CPU Port of ethernet Switch ksz9563 not working

Hi there,
we are trying to integrate a Microchip Switch IC, the ksz9563 with the imx8mp processor on the Verdin iMX8M Plus SoC. The switch is supported by the driver ksz9477 together with ksz9477_i2c since its management interface is connected via I²C.
The RGMII of the ksz9563 is connected to the ETH_2_RGMII_* pins of the SoC.

What is working:
After bringing up a bridge as described in this Microchip application note https://ww1.microchip.com/downloads/en/Appnotes/AN3761-KSZ-DSA-Driver-Utilization-00003761A.pdf switching forwarding between the two front facing ports works just fine.
All network interfaces show up as expected (three of them, for the ksz9563).

What does not work:
However, the CPU-Port of the switch does not work as expected.
Using tcpdump, I can see that receiving on the br0 interface does actually work, no packets are transmitted, though:

# tcpdump -i br0
[  875.179144] device br0 entered promiscuous mode
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
00:15:17.039849 ARP, Request who-has tell, length 46
00:15:17.039872 ARP, Reply is-at 00:14:2d:7d:2b:b1 (oui Unknown), length 28
00:15:24.743673 IP > UDP, length 175
00:15:25.744274 IP > UDP, length 175
00:15:26.745756 IP > UDP, length 175
00:15:27.746397 IP > UDP, length 175
00:16:15.836623 IP6 fe80::214:2dff:fe7d:2bb1 > ff02::2: ICMP6, router solicitation, length 16
00:17:24.750067 IP > UDP, length 175
00:17:25.751524 IP > UDP, length 175
00:17:26.752436 IP > UDP, length 175
00:17:27.752770 IP > UDP, length 175

The first two lines of output are triggered by trying to ping from my connected PC, however, the ARP Reply is never received. I checked using Wireshark, and there is not a single received frame from the imx8 host, ever.

Here come the important parts of the device tree.
First of all the configuration of the management interface via I²C

&i2c2 {
	clock-frequency = <100000>;
	status = "okay";

	ksz9563: switch@5f {
		compatible = "microchip,ksz9563";
		reg = <0x5f>;
		status = "okay";

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

			port@0 {
				reg = <0>;
				label = "lan0";
			port@1 {
				reg = <1>;
				label = "lan1";
			port@2 {
				reg = <2>;
				label = "cpu";
				ethernet = <&fec>;
				phy-mode = "rgmii-txid";

				fixed-link {
					speed = <1000>;

This what our “fec” node looks like and I am highly uncertain as to whether this is the correct way to do it.

&fec {
	 /delete-property/ phy-handle;

	phy-supply = <&reg_3p3v>;
	phy-mode = "rgmii-txid";
	#address-cells = <1>;
	#size-cells = <0>;
	status = "okay";
	/delete-node/ mdio;

	fixed-link {
        speed = <1000>;

The relevant log messages look like this (i snipped some noise):

[    3.132168] ksz9477-switch 1-005f: Found KSZ9893
[    3.194101] ksz9477-switch 1-005f: Port2: using phy mode rgmii-txid
[    3.266107] ksz9477-switch 1-005f: configuring for fixed/rgmii-txid link mode
[    3.273426] ksz9477-switch 1-005f: Link is Up - 1Gbps/Full - flow control off
[    3.274563] ksz9477-switch 1-005f lan0 (uninitialized): PHY [dsa-0.0:00] driver [Microchip KSZ9477] (irq=POLL)
[    3.292755] ksz9477-switch 1-005f lan1 (uninitialized): PHY [dsa-0.0:01] driver [Microchip KSZ9477] (irq=POLL)
[    3.303479] device eth0 entered promiscuous mode
[    3.308287] DSA: tree 0 setup
[   10.911549] Generic PHY fixed-0:00: attached PHY driver (mii_bus:phy_addr=fixed-0:00, irq=POLL)
[   10.921342] fec 30be0000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
[   10.942562] ksz9477-switch 1-005f lan0: configuring for phy/gmii link mode
[   10.952178] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   10.978501] ksz9477-switch 1-005f lan0: Link is Up - 1Gbps/Full - flow control rx/tx
[   10.990194] ksz9477-switch 1-005f lan1: configuring for phy/gmii link mode
[   10.998286] IPv6: ADDRCONF(NETDEV_CHANGE): lan0: link becomes ready
[   11.010483] br0: port 1(lan0) entered blocking state
[   11.015498] br0: port 1(lan0) entered disabled state
[   11.032634] device lan0 entered promiscuous mode
[   11.049257] br0: port 2(lan1) entered blocking state
[   11.054276] br0: port 2(lan1) entered disabled state
[   11.071825] device lan1 entered promiscuous mode
[   11.089762] br0: port 1(lan0) entered blocking state
[   11.094766] br0: port 1(lan0) entered forwarding state

Your help is highly appreciated!

Toradex 0058 Verdin iMX8M Plus Quad 4GB WB IT V1.0D
Custom Carrier Board
Linux 5.15 (BSP 6, custom image via buildroot)

Hello @armin.schmidt,

could you share your schematic? you can send it to support@toradex.com

Beat Regards,

Matthias Gohlke

Hello @matthias.tx,
did you receive the schematics I sent you?

Best regards,

Armin Schmidt

Hello @armin.schmidt,

Yes, we got it. There was a public holiday here yesterday so there might be some delay in response.

Best Regards,


Hi @armin.schmidt!

Are you doing this from a device tree overlay? On device tree overlays, delete-* instructions don’t have the expected effect.

Some references:

Best regards,

Hi @henrique.tx!

No, the “&fec” block is part a .dtsi file and it actually does what it so supposed to do.
If I skip this block, thereby leaving the “phy-handle” property (and the subnode “mdio”) in the device tree, the kernel log shows an error message about not being able to connect to the PHY at all.

Best regards,

Hi @armin.schmidt,

just to exclude that we have a signal integrity issue here please try the following.

Please try to operate the interface at lower speeds like 10 or 100 MBit.

fixed-link {
        speed = <1000>;

Also, try to measure the clock and data line and look at the eye diagram on the scope.

Best Regards,