Re: DSA driver kernel extension for dsa mv88e6190 switch

From: Andrew Lunn <andrew@lunn.ch>
To: Zoran Stojsavljevic <zoran.stojsavljevic@gmail.com>
Cc: netdev@vger.kernel.org
Subject: Re: DSA driver kernel extension for dsa mv88e6190 switch
Date: Sat, 28 Sep 2019 17:20:22 +0200	[thread overview]
Message-ID: <20190928152022.GE25474@lunn.ch> (raw)
In-Reply-To: <CAGAf8LxAbDK7AUueCv-2kcEG8NZApNjQ+WQ1XO89+5C-SLAbPw@mail.gmail.com>

On Sat, Sep 28, 2019 at 01:00:43AM +0200, Zoran Stojsavljevic wrote:
> Hello Andrew,
> 
> > You should not need any kernel patches for switch side RGMII
> > delays. rgmii-id in the DT for the switch CPU port should be enough.
> > Some of the vf610-zii platforms use it.
> 
> It should, but it does NOT work. IT is clearly stated in port.c, in f-n:
> static int mv88e6xxx_port_set_rgmii_delay(struct mv88e6xxx_chip *chip, int port,
>                                           phy_interface_t mode)
> 
> The logic analyser shows MDIO write to register 0x01, which is 0x6003.
> Seems the correct value.
> 
> But, at the very end, ethtool shows that this clock skew is NOT
> inserted.

How do you see this with ethtool?

> I see on RX side CRC errors. Every ethernet frame while
> pinging.

But TX works? Maybe the FEC is doing some sort of delay, even if it
has a hardware bug.

> I see another interesting fact, the dmesg, which you could see here:
> https://pastebin.com/igXS6eXe
> 
> [    1.182273] DEBUG INFO! <- addr: 0x00 reg: 0x03 val: 0x1901
> [    1.187888] mv88e6085 2188000.ethernet-1:00: switch 0x1900
> detected: Marvell 88E6190, revision 1
> [    1.219804] random: fast init done
> [    1.225334] libphy: mv88e6xxx SMI: probed
> [    1.232709] fec 2188000.ethernet eth0: registered PHC device 0
> 
> [    1.547946] DEBUG INFO! <- addr: 0x00 reg: 0x03 val: 0x1901
> [    1.553542] mv88e6085 2188000.ethernet-1:00: switch 0x1900
> detected: Marvell 88E6190, revision 1
> [    1.555432]  mmcblk1: p1
> [    1.598106] libphy: mv88e6xxx SMI: probed
> [    1.740362] DSA: tree 0 setup
> 
> There are two distinct accesses while driver configures the switch. Why???

This happens when the driver is missing a resource during probe.  It
returns the error -EPROBE_DEFER, and the linux driver core will try
the probe again later. Probably the second time all the resources it
needs will be present and the probe will be successful.

I will probably have a some patches during the next kernel merge cycle
to make this a bit more efficient.

> I was not able to explain this to me... Or find explanation using google?!
> 
> > gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>; is wrong. It probably
> > should be reset-gpios. The rest looks O.K.
> 
> I will follow the advise, but I do not think this is an obstacle.

No, it is not an obstacle, but it is still wrong.

> 
> > Please show me the configuration steps you are doing? How are you
> > configuring the FEC and the switch interfaces?
> 
> Forgive me for my ignorance, but I have no idea what you have asked me for?

ip link set eth0 up
ip link set lan0 up
ip link set lan1 up
ip link name br0 type bridge
ip link set br0 up
ip link lan0 master br0
ip link lan1 master br0

   Andrew