Hello,
we were trying to connect KSZ8795 switch via MDIO to imx8qx, but it was wrong, because not all features are supported via SPI. Now we are trying to connect it via SPI, but there is still something amiss. At first we same problems as in KSZ8795-SPI-setup and changed from native chip select to gpio and at least some communication happens with switch.
Kernel is built with following options, .ko files are built and can be loaded with insmod
CONFIG_NET_DSA=y
CONFIG_NET_DSA_TAG_KSZ=y
CONFIG_NET_DSA_MICROCHIP_KSZ8795=m
CONFIG_NET_DSA_MICROCHIP_KSZ_COMMON=m
CONFIG_NET_DSA_MICROCHIP_KSZ8795_SPI=m
CONFIG_REGMAP_SPI=y
There are two problems.
1. When ksz8795_spi is loaded for the first time it fails with "ksz8795-switch: probe of spi1.0 failed with error -22" .We've checked communication and think that i.MX for some reason toggles spi_clk shortly before communication which causes following communication to fail. Only the first attempt fails. Every next attempt doesn't have this toggle and some data is received in all following attempts. Do you have any idea what could be causing this toggle on spi_clk?
2. After that we rmmod and insmod spi driver again and spi communication looks better this time, e.g. first 4 data transfers are read register 0, and response is 0x8791 which is correct for KSZ8795. However after one more read and 2 write operations nothing else happens, no output in dmesg and "Unable cannot connect to phy" if attempting to up the interface.
[ 37.182247] 000: fec 5b040000.ethernet eth0: Unable to connect to phy
We based our device tree on this example. KSZ8795 is connected to SPI0 and FEC1 is connected to CPU port. There is README for the driver
The KSZ8795 driver creates a virtual MDIO bus and exposes each port in the
switch as a PHY device under that MDIO bus. To access the switch from the
network controller driver a PHY device with PHY id 0 needs to be retrieved
from the virtual MDIO bus. Inside the PHY device's private data is a pointer
to the switch structure. With that pointer all the switch functions can be
accessed.
Unfortunately I don't understand the implications of this description. Is following device tree correct or are there some changes necessary?
&lpspi0 {
#address-cells = <1>;
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_lpspi0>, <&pinctrl_lpspi0_gpio>;
dma-names = "tx","rx";
dmas = <&edma2 1 0 0>, <&edma2 0 0 1>;
clocks = <&clk IMX_SC_R_SPI_0 IMX_SC_PM_CLK_PER>,
<&dma_ipg_clk>;
cs-gpios = <&lsio_gpio1 8 GPIO_ACTIVE_LOW>, <&lsio_gpio1 7 GPIO_ACTIVE_LOW>;
fsl,spi-num-chipselects = <2>;
status = "okay";
ksz8795: ksz8795@0 {
compatible = "microchip,ksz8795";
reg = <0>;
spi-max-frequency = <2000000>;
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 = <3>;
label = "lan4";
};
port@4 {
reg = <4>;
label = "lan5";
};
port@5 {
reg = <5>;
label = "cpu";
ethernet = <ðphy0>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
};
};
&fec1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_fec1>;
phy-mode = "rgmii-id";
phy-handle = <ðphy0>;
fsl,magic-packet;
local-mac-address = [00 11 22 33 44 55];
status = "okay";
mdio {
#address-cells = <1>;
#size-cells = <0>;
ethphy0: ethernet-phy@0 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <0>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
};
Thank you in advance!
1. Unfortunately there is still the same short drop in SPI CLK, with the new 5.4.47_2.2.0 kernel. Do you have any ideas what else we could check?
2. There is also SPI driver for KSZ8795 provided by microchip for evaluation board.
What do you think, is existing KSZ8795 driver sufficient ( https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/net/dsa/microchip?h=imx_5.4.47_2.2... ) or should the driver from the manufacturer be used?
