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