netdev - Re: i.MX6S/DL and QCA8334 switch using DSA driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180426140629.GB15370@lunn.ch>
Date:   Thu, 26 Apr 2018 16:06:29 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Michal Vokáč <vokac.m@...il.com>
Cc:     netdev@...r.kernel.org,
        "Andrew Lunn <andrew@...n.ch>; Vivien Didelot
        <vivien.didelot@...oirfairelinux.com>; Florian Fainelli" 
        <f.fainelli@...il.com>
Subject: Re: i.MX6S/DL and QCA8334 switch using DSA driver - CPU port not
 working

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.

>  - Mainline DSA drivers
>  - Mainline qca8k driver
> 
> 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")

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

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

    Andrew