Re: i.MX6S/DL and QCA8334 switch using DSA driver - CPU port not working

From: "Michal Vokáč" <vokac.m@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: netdev@vger.kernel.org,
	Vivien Didelot <vivien.didelot@savoirfairelinux.com>,
	Florian Fainelli <f.fainelli@gmail.com>
Subject: Re: i.MX6S/DL and QCA8334 switch using DSA driver - CPU port not working
Date: Fri, 4 May 2018 10:45:17 +0200	[thread overview]
Message-ID: <573258a9-b115-ca4a-121c-5174798d5621@gmail.com> (raw)
In-Reply-To: <20180430132025.GF10066@lunn.ch>

On 30.4.2018 15:20, Andrew Lunn wrote:
>> Using rgmii-id for the port is not valid as the qca8k driver does not support
>> that mode. It only supports rgmii and sgmii. I think this is actually not
>> correct. When phy-mode is set to rgmii for port the qca8k driver configures
>> internal delays in the switch. So it behaves like rgmii-id I think.
>>
>> Should not it be:
>>
>> --- a/drivers/net/dsa/qca8k.c
>> +++ b/drivers/net/dsa/qca8k.c
>> @@ -474,7 +474,7 @@ qca8k_set_pad_ctrl(struct qca8k_priv *priv, int port, int mode)
>>   	 * PHY or MAC.
>>   	 */
>>   	switch (mode) {
>> -	case PHY_INTERFACE_MODE_RGMII:
>> +	case PHY_INTERFACE_MODE_RGMII_ID:
>>   	qca8k_write(priv, reg,
>> 		    QCA8K_PORT_PAD_RGMII_EN |
>> 		    QCA8K_PORT_PAD_RGMII_TX_DELAY(3) |
> 
> We have to be careful cleaning this up. It has the potential to break
> existing boards when using an old device tree blob.

Oh, I see. Thanks for pointing this out.

Some news to the problem with the non-working CPU port.
Andrew, thank you very mych for the ideas how to debug the issue.
I tried what you suggested but have no luck. FYI Now I am doing all my tests
with linux-stable.

First of all I tried to make work my old phy driver for the switch with latest
kernel. It works on v4.1.46 but did not on v4.17-rc2 - no IP@ on eth0.
So a very same issue as I have with the DSA. Bisecting the kernel picked:

d5c3d84 ("net: phy: Avoid polling PHY with PHY_IGNORE_INTERRUPTS")

Fixed that by using PHY_POLL in my driver. I was hoping that I may have similar
issue when using DSA but it looks OK. This is with the DSA enabled:

  # dmesg | grep PHY
  [    3.452536] Generic PHY 2188000.ethernet-1:01: attached PHY driver [Generic PHY] (mii_bus:phy_addr=2188000.ethernet-1:01, irq=POLL)
  [    3.453437] Generic PHY 2188000.ethernet-1:02: attached PHY driver [Generic PHY] (mii_bus:phy_addr=2188000.ethernet-1:02, irq=POLL)
  [   20.769281] Generic PHY fixed-0:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=fixed-0:00, irq=POLL)

Anyway, now I am sure that I can use RGMII interface with mainline when I am
not using DSA and phy-mode is set to rgmii and I use QCA8K_PORT_PAD_RGMII_TX_DELAY(2)
and QCA8K_PORT_PAD_RGMII_RX_DELAY(2).

To debug the non-working CPU port with DSA I tried these kernel versions:

  - v4.8-rc6-1085-g6b93fb4 - NOT OK
    - Can not go lower than this version. qca8k driver was introduced here.
  - 4.9.84 - NOT OK
  - 4.17-rc2 - NOT OK

Some RGMII delay tunning attempts with v4.17-rc2:

phy-mode (fec)	Rx/Tx delay	result
--------------------------------------
rgmii		0/0		NOT OK
rgmii		1/1		NOT OK
rgmii		2/2		NOT OK
rgmii		3/3		NOT OK
rgmii-id	0/0		NOT OK
rgmii-id	1/1		NOT OK
rgmii-id	2/2		NOT OK
rgmii-id	3/3		NOT OK

I am out of ideas how to further debug this.
Any additional adivce will be much appreciated.

Thanks, Michal.