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

["Michal Vokáč" <vokac.m@gmail.com>]

On 26.4.2018 16:06, Andrew Lunn wrote:
> On Thu, Apr 26, 2018 at 03:37:33PM +0200, Michal Vokáč wrote:
>>
>>   - Linux 4.9.84 (Freescale 4.9-1.0.x-imx branch)
> 
> Hi Michal
> 
> Please use mainline, not the freescale fork. For DSA, there is nothing
> you need in the freescale fork. Once it works with mainline, you can
> then figure out what needs to be done to make the fork work.

Hi Andrew,
Thanks for such a quick reply!

OK, good point, I will go this way - mainline first, fork then.

>> The Freescale branch does not introduce any changes to the DSA nor to the QCA8K
>> drivers from mainline.
> 
> Does it have
> fbbeefdd2104 ("net: fec: Allow reception of frames bigger than 1522 bytes")

Yes, this one was backported to 4.9.74 and is in the freescale branch too.

>> To make the bridge work I need to enable forwarding across all the switch ports
>> at setup.
>>
>> --- a/drivers/net/dsa/qca8k.c
>> +++ b/drivers/net/dsa/qca8k.c
>> @@ -578,12 +578,12 @@ qca8k_setup(struct dsa_switch *ds)
>>     		if (ds->enabled_port_mask & BIT(i))
>>     			qca8k_port_set_status(priv, i, 0);
>> -	/* Forward all unknown frames to CPU port for Linux processing */
>> +	/* Forward all unknown frames to all pors */
>>     	qca8k_write(priv, QCA8K_REG_GLOBAL_FW_CTRL1,
>>     		    BIT(0) << QCA8K_GLOBAL_FW_CTRL1_IGMP_DP_S |
>> -		    BIT(0) << QCA8K_GLOBAL_FW_CTRL1_BC_DP_S |
>> -		    BIT(0) << QCA8K_GLOBAL_FW_CTRL1_MC_DP_S |
>> -		    BIT(0) << QCA8K_GLOBAL_FW_CTRL1_UC_DP_S);
>> +		    0x7f << QCA8K_GLOBAL_FW_CTRL1_BC_DP_S |
>> +		    0x7f << QCA8K_GLOBAL_FW_CTRL1_MC_DP_S |
>> +		    0x7f << QCA8K_GLOBAL_FW_CTRL1_UC_DP_S);
>>     	/* Setup connection between CPU port & user ports */
>>     	for (i = 0; i < DSA_MAX_PORTS; i++) {
>> --
> 
> This is probably because you don't have a working CPU port.  If that
> worked, all unknown frames would be passed to the software bridge. It
> would then either flood them out all ports, or if it knows the
> destination MAC address, out one specific port. The should be enough
> to make the destination reply, at which point the switch learns the
> MAC address, and it is no longer unknown.
> 
> So lets leave this alone for the moment.

First attempt - pure mainline 4.9.84 without my patch.
CPU port not working, bridge not working.

>> But I am still not able to make work the CPU port though.
>>
>>   # udhcpc -i eth2
>>   Sending discover...
>>   [FOREVER]
>>
>> The same for eth1, eth2 and br0.
>>
>> I suspect the problem may be at different levels:
>>
>>   - The RGMII interface is not properly configured
>>    -- at the CPU side, or
>>    -- at the switch chip side.
>>   - Some setup that I have not done needs to be done (in userspace).
> 
> Your user space setup look O.K.
> 
> Try playing with RGMII delays. Set the phy-mode to rgmii-id.

OK, I will try some combinations and also to tune the numbers in the driver.
That part is actually quite confusing to me. phy-mode can be set for the fec
and for the port. For the fec I am now using rgmii as that is what we were
using before and it worked. Though from my understanding of the ethernet
binding doc it totally make sense to use rgmii-id for the fec.
I tried that and it did not help.

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) |