Discussion:
[OpenWrt-Devel] AR8334 switch support
Christian Mehlis
2015-04-21 11:51:49 UTC
Permalink
I was involved in making upstream support for the compex wpj344 and came
across the AR8334 embedded switch used on this board.

Unfortunately it seems that this switch is not jet supported by the
ar8327/ar8216 driver in openwrt.

The vendor just did this to their openwrt based sdk:

--- a/target/linux/generic/files/drivers/net/phy/ar8327.c
+++ b/target/linux/generic/files/drivers/net/phy/ar8327.c
@@ -508,8 +508,10 @@ ar8327_hw_config_pdata(struct ar8xxx_priv *priv,
data->port6_status = ar8327_get_port_init_status(&pdata->port6_cfg);

t = ar8327_get_pad_cfg(pdata->pad0_cfg);
+#if 0
if (chip_is_ar8337(priv))
t |= AR8337_PAD_MAC06_EXCHANGE_EN;
+#endif

ar8xxx_write(priv, AR8327_REG_PAD0_MODE, t);
t = ar8327_get_pad_cfg(pdata->pad5_cfg);
--
I tied to find a more generic solution but it seems that my ar8334 is
identifying itself as "Atheros AR8337 rev. 2 switch". The identification
read from the device is ver:0x13 rev:0x02.

If you have more information on that chip or some source code, feel free
to reply (or send me a mail).

The board support went upstream in the mean time:

https://dev.openwrt.org/changeset/45527

Best
Christian
Heiner Kallweit
2015-04-21 15:19:11 UTC
Permalink
All I found regarding AR8334/QCA8334 is that it supposedly has four ports.
(There was even an AR8335 with five ports mentioned).
Considering the port / phy layout of AR8337 and the existing boards
with AR8334 I'd assume that AR8334 has just two phy's.
The 8327/8337 code of the driver at least would have to be extended to
not assume a fixed 7 port / 5 phy layout.

Apart from the fact that the driver treats AR8334 as a 7 port / 5 phy
chip it also applies the fixups for AR8327 rev. 2, what is at least
questionnable.

Is the AR8334 fully functional with this slightly modified driver or
are certain thing not working?

Rgds, Heiner
Post by Christian Mehlis
I was involved in making upstream support for the compex wpj344 and came
across the AR8334 embedded switch used on this board.
Unfortunately it seems that this switch is not jet supported by the
ar8327/ar8216 driver in openwrt.
--- a/target/linux/generic/files/drivers/net/phy/ar8327.c
+++ b/target/linux/generic/files/drivers/net/phy/ar8327.c
@@ -508,8 +508,10 @@ ar8327_hw_config_pdata(struct ar8xxx_priv *priv,
data->port6_status = ar8327_get_port_init_status(&pdata->port6_cfg);
t = ar8327_get_pad_cfg(pdata->pad0_cfg);
+#if 0
if (chip_is_ar8337(priv))
t |= AR8337_PAD_MAC06_EXCHANGE_EN;
+#endif
ar8xxx_write(priv, AR8327_REG_PAD0_MODE, t);
t = ar8327_get_pad_cfg(pdata->pad5_cfg);
--
I tied to find a more generic solution but it seems that my ar8334 is
identifying itself as "Atheros AR8337 rev. 2 switch". The identification
read from the device is ver:0x13 rev:0x02.
If you have more information on that chip or some source code, feel free to
reply (or send me a mail).
https://dev.openwrt.org/changeset/45527
Best
Christian
_______________________________________________
openwrt-devel mailing list
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Christian Mehlis
2015-04-21 17:06:51 UTC
Permalink
Post by Heiner Kallweit
All I found regarding AR8334/QCA8334 is that it supposedly has four ports.
(There was even an AR8335 with five ports mentioned).
Considering the port / phy layout of AR8337 and the existing boards
with AR8334 I'd assume that AR8334 has just two phy's.
The 8327/8337 code of the driver at least would have to be extended to
not assume a fixed 7 port / 5 phy layout.
I see.
Post by Heiner Kallweit
Apart from the fact that the driver treats AR8334 as a 7 port / 5 phy
chip it also applies the fixups for AR8327 rev. 2, what is at least
questionnable.
Is the AR8334 fully functional with this slightly modified driver or
are certain thing not working?
With the vendor patch, Linux is able to talk to the switch, and
send/receive data.

Strange things I discovered:

1) on "plug out"

Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Port 3 is down

is printed, but linux keeps the interface as UP.

2) # swconfig list (on this board) shows multiple switches?!
Found: switch0 - ag71xx-mdio.0
Found: switch1 - eth1

3) swconfig dev switch0 show
works as expected.

files attached:
1. boot with ports connected
2. disconnect plugs
3. dump the files

If you can supply some sort of patch for the 4 port switch, I would be
happy to test. -> I want to have upstream support for the switch (and
the compex wpj344).

In case you really need the actual hardware (the compex wpj344) I can
send you a board.

Best
Christian
Heiner Kallweit
2015-04-22 17:01:09 UTC
Permalink
Post by Christian Mehlis
Post by Heiner Kallweit
All I found regarding AR8334/QCA8334 is that it supposedly has four ports.
(There was even an AR8335 with five ports mentioned).
Considering the port / phy layout of AR8337 and the existing boards
with AR8334 I'd assume that AR8334 has just two phy's.
The 8327/8337 code of the driver at least would have to be extended to
not assume a fixed 7 port / 5 phy layout.
I see.
Post by Heiner Kallweit
Apart from the fact that the driver treats AR8334 as a 7 port / 5 phy
chip it also applies the fixups for AR8327 rev. 2, what is at least
questionnable.
Is the AR8334 fully functional with this slightly modified driver or
are certain thing not working?
With the vendor patch, Linux is able to talk to the switch, and send/receive data.
1) on "plug out"
Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Port 3 is down
Can you provide a complete dmesg output?
Post by Christian Mehlis
is printed, but linux keeps the interface as UP.
2) # swconfig list (on this board) shows multiple switches?!
Found: switch0 - ag71xx-mdio.0
Found: switch1 - eth1
switch1 is the AR9344-internal (100MBit only) switch.
Post by Christian Mehlis
3) swconfig dev switch0 show
works as expected.
1. boot with ports connected
2. disconnect plugs
3. dump the files
If you can supply some sort of patch for the 4 port switch, I would be happy to test. -> I want to have upstream support for the switch (and the compex wpj344).
In case you really need the actual hardware (the compex wpj344) I can send you a board.
Best
Christian
W/o having seen the datasheets for AR8337/AR8334 I'm hesitant to propose a patch.
1. AR8334 identifies itself as AR8337/rev.2. There might be a real AR8337/rev.2 with 7 ports. How to tell between these two chips?
2. The AR8334 name seems to indicate that it's the same as AR8337 just with 4 ports. The required padding patch however shows
that the difference is not only the number of ports. Having said that there might be more differences.

Rgds, Heiner
Christian Mehlis
2015-04-23 12:43:12 UTC
Permalink
Post by Heiner Kallweit
Can you provide a complete dmesg output?
Bootlog is available here:
http://wiki.openwrt.org/toh/compex/wpj344#openwrt_upstream_bootlog

Dmesg is attached.
Post by Heiner Kallweit
W/o having seen the datasheets for AR8337/AR8334 I'm hesitant to propose a patch.
1. AR8334 identifies itself as AR8337/rev.2. There might be a real AR8337/rev.2 with 7 ports. How to tell between these two chips?
Perhaps there are some other registers where the number of ports are
available? But I don't have any datasheets to look into...

Best
Christian
Heiner Kallweit
2015-04-24 18:05:01 UTC
Permalink
Post by Christian Mehlis
Post by Heiner Kallweit
Can you provide a complete dmesg output?
http://wiki.openwrt.org/toh/compex/wpj344#openwrt_upstream_bootlog
Dmesg is attached.
Post by Heiner Kallweit
W/o having seen the datasheets for AR8337/AR8334 I'm hesitant to propose a patch.
1. AR8334 identifies itself as AR8337/rev.2. There might be a real AR8337/rev.2 with 7 ports. How to tell between these two chips?
Perhaps there are some other registers where the number of ports are available? But I don't have any datasheets to look into...
Best
Christian
This patch tries to identify an AR8334/AR8335 by checking for non-existent PHYs.
I have systems with AR8327 only, the patch doesn't do any harm on them at least.
Could you please test this patch and provide the dmesg output?

Rgds, Heiner

---
target/linux/generic/files/drivers/net/phy/ar8216.c | 8 ++++----
target/linux/generic/files/drivers/net/phy/ar8216.h | 21 +++++++++++++++++++--
target/linux/generic/files/drivers/net/phy/ar8327.c | 17 ++++++++++++++---
3 files changed, 37 insertions(+), 9 deletions(-)

diff --git a/target/linux/generic/files/drivers/net/phy/ar8216.c b/target/linux/generic/files/drivers/net/phy/ar8216.c
index e39d540..25bbfc2 100644
--- a/target/linux/generic/files/drivers/net/phy/ar8216.c
+++ b/target/linux/generic/files/drivers/net/phy/ar8216.c
@@ -38,7 +38,7 @@
#include "ar8216.h"

extern const struct ar8xxx_chip ar8327_chip;
-extern const struct ar8xxx_chip ar8337_chip;
+extern const struct ar8xxx_chip ar833x_chip;

#define AR8XXX_MIB_WORK_DELAY 2000 /* msecs */

@@ -1576,8 +1576,8 @@ ar8xxx_id_chip(struct ar8xxx_priv *priv)
case AR8XXX_VER_AR8327:
priv->chip = &ar8327_chip;
break;
- case AR8XXX_VER_AR8337:
- priv->chip = &ar8337_chip;
+ case AR8XXX_VER_AR833X:
+ priv->chip = &ar833x_chip;
break;
default:
pr_err("ar8216: Unknown Atheros device [ver=%d, rev=%d]\n",
@@ -1856,7 +1856,7 @@ ar8xxx_phy_config_aneg(struct phy_device *phydev)
static const u32 ar8xxx_phy_ids[] = {
0x004dd033,
0x004dd034, /* AR8327 */
- 0x004dd036, /* AR8337 */
+ 0x004dd036, /* AR833X */
0x004dd041,
0x004dd042,
0x004dd043, /* AR8236 */
diff --git a/target/linux/generic/files/drivers/net/phy/ar8216.h b/target/linux/generic/files/drivers/net/phy/ar8216.h
index 0f53f23..a50fb9d 100644
--- a/target/linux/generic/files/drivers/net/phy/ar8216.h
+++ b/target/linux/generic/files/drivers/net/phy/ar8216.h
@@ -334,7 +334,7 @@ enum {
AR8XXX_VER_AR8236 = 0x03,
AR8XXX_VER_AR8316 = 0x10,
AR8XXX_VER_AR8327 = 0x12,
- AR8XXX_VER_AR8337 = 0x13,
+ AR8XXX_VER_AR833X = 0x13,
};

#define AR8XXX_NUM_ARL_RECORDS 100
@@ -409,6 +409,8 @@ struct ar8xxx_priv {
void *chip_data;
bool initialized;
bool port4_phy;
+ bool unavailable_phys[AR8XXX_NUM_PHYS];
+ int num_unavailable_phys;
char buf[2048];
struct arl_entry arl_table[AR8XXX_NUM_ARL_RECORDS];
char arl_buf[AR8XXX_NUM_ARL_RECORDS * 32 + 256];
@@ -562,9 +564,24 @@ static inline bool chip_is_ar8327(struct ar8xxx_priv *priv)
return priv->chip_ver == AR8XXX_VER_AR8327;
}

+static inline bool chip_is_ar833x(struct ar8xxx_priv *priv)
+{
+ return priv->chip_ver == AR8XXX_VER_AR833X;
+}
+
+static inline bool chip_is_ar8334(struct ar8xxx_priv *priv)
+{
+ return chip_is_ar833x(priv) && priv->num_unavailable_phys == 3;
+}
+
+static inline bool chip_is_ar8335(struct ar8xxx_priv *priv)
+{
+ return chip_is_ar833x(priv) && priv->num_unavailable_phys == 2;
+}
+
static inline bool chip_is_ar8337(struct ar8xxx_priv *priv)
{
- return priv->chip_ver == AR8XXX_VER_AR8337;
+ return chip_is_ar833x(priv) && priv->num_unavailable_phys == 0;
}

static inline void
diff --git a/target/linux/generic/files/drivers/net/phy/ar8327.c b/target/linux/generic/files/drivers/net/phy/ar8327.c
index 07e837e..a25372f 100644
--- a/target/linux/generic/files/drivers/net/phy/ar8327.c
+++ b/target/linux/generic/files/drivers/net/phy/ar8327.c
@@ -620,7 +620,18 @@ ar8327_hw_config_of(struct ar8xxx_priv *priv, struct device_node *np)
static int
ar8327_hw_init(struct ar8xxx_priv *priv)
{
- int ret;
+ int i, ret;
+
+ for (i = 0; i < AR8XXX_NUM_PHYS; i++)
+ /* certain bits are always set if the PHY exists */
+ if (!mdiobus_read(priv->mii_bus, i, MII_BMSR)) {
+ priv->unavailable_phys[i] = true;
+ priv->num_unavailable_phys++;
+ dev_info(&priv->phy->dev, "PHY %d not available\n", i);
+ }
+ if (chip_is_ar833x(priv))
+ dev_info(&priv->phy->dev, "Detected AR833%d switch\n",
+ AR8327_NUM_PORTS - priv->num_unavailable_phys);

priv->chip_data = kzalloc(sizeof(struct ar8327_data), GFP_KERNEL);
if (!priv->chip_data)
@@ -1201,12 +1212,12 @@ const struct ar8xxx_chip ar8327_chip = {
.mib_func = AR8327_REG_MIB_FUNC
};

-const struct ar8xxx_chip ar8337_chip = {
+const struct ar8xxx_chip ar833x_chip = {
.caps = AR8XXX_CAP_GIGE | AR8XXX_CAP_MIB_COUNTERS,
.config_at_probe = true,
.mii_lo_first = true,

- .name = "Atheros AR8337",
+ .name = "Atheros AR833X",
.ports = AR8327_NUM_PORTS,
.vlans = AR8X16_MAX_VLANS,
.swops = &ar8327_sw_ops,
--
2.3.5
Christian Mehlis
2015-04-27 12:20:14 UTC
Permalink
Post by Heiner Kallweit
Could you please test this patch and provide the dmesg output?
I tried your patch - dmesg is attached.

After the first run without success:
[ 0.890000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Detected
AR8337 switch

I tweaked your patch a bit to print out more (attached).

############################################################

I also changed:
+ for (i = 0; i < AR8XXX_NUM_PHYS; i++) {
to
+ for (i = 0; i < AR8327_NUM_PORTS; i++) {

with this change we get:

[ 0.850000] switch0: Atheros AR833X rev. 2 switch registered on
ag71xx-mdio.0
[ 0.860000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: PHY 0
available
[ 0.860000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: PHY 1
available
[ 0.870000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: PHY 2
available
[ 0.880000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: PHY 3
available
[ 0.890000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: PHY 4
available
[ 0.890000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: PHY 5
available
[ 0.900000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: PHY 6
available
[ 0.910000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Detected
AR8337 switch

#############################################################

It seems, that your phy based test is not working on ar8334...

Can we test other registers? I'll give it a try.

Best
Christian
Heiner Kallweit
2015-04-27 13:06:06 UTC
Permalink
Here comes a slight modification / extension to display the return
value of the BMSR read command.
Maybe the read command returns an error instead of 0 for non-existent PHY's.
There is no AR8XXX chip with a PHY 5 or PHY 6.
Could you please provide te dmesg output of this patch version?

Thanks.


for (i = 0; i < AR8327_NUM_PORTS; i++) {
int bmsr = mdiobus_read(priv->mii_bus, i, MII_BMSR);
/* certain bits are always set if the PHY exists */
if (!bmsr) {
priv->unavailable_phys[i] = true;
priv->num_unavailable_phys++;
dev_info(&priv->phy->dev, "PHY %d not available\n", i);
} else {
dev_info(&priv->phy->dev, "PHY %d available, BMSR =
0x%x\n", i, bmsr);
}
Post by Christian Mehlis
Post by Heiner Kallweit
Could you please test this patch and provide the dmesg output?
I tried your patch - dmesg is attached.
[ 0.890000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Detected
AR8337 switch
I tweaked your patch a bit to print out more (attached).
############################################################
+ for (i = 0; i < AR8XXX_NUM_PHYS; i++) {
to
+ for (i = 0; i < AR8327_NUM_PORTS; i++) {
[ 0.850000] switch0: Atheros AR833X rev. 2 switch registered on
ag71xx-mdio.0
[ 0.860000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: PHY 0
available
[ 0.860000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: PHY 1
available
[ 0.870000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: PHY 2
available
[ 0.880000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: PHY 3
available
[ 0.890000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: PHY 4
available
[ 0.890000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: PHY 5
available
[ 0.900000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: PHY 6
available
[ 0.910000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Detected
AR8337 switch
#############################################################
It seems, that your phy based test is not working on ar8334...
Can we test other registers? I'll give it a try.
Best
Christian
Christian Mehlis
2015-04-27 15:47:26 UTC
Permalink
Post by Heiner Kallweit
Could you please provide te dmesg output of this patch version?
[ 0.850000] switch0: Atheros AR833X rev. 2 switch registered on
ag71xx-mdio.0
[ 0.860000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: PHY 0
available, BMSR = 0x7949
[ 0.870000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: PHY 1
available, BMSR = 0x7949
[ 0.870000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: PHY 2
available, BMSR = 0x7969
[ 0.880000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: PHY 3
available, BMSR = 0x7949
[ 0.890000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: PHY 4
available, BMSR = 0x7949
[ 0.900000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: PHY 5
available, BMSR = 0xffff
[ 0.910000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: PHY 6
available, BMSR = 0xffff
[ 0.920000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Detected
AR8337 switch

Best
Christian
Heiner Kallweit
2015-04-27 18:56:20 UTC
Permalink
Post by Heiner Kallweit
Could you please provide te dmesg output of this patch version?
[ 0.850000] switch0: Atheros AR833X rev. 2 switch registered on ag71xx-mdio.0
[ 0.860000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: PHY 0 available, BMSR = 0x7949
[ 0.870000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: PHY 1 available, BMSR = 0x7949
[ 0.870000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: PHY 2 available, BMSR = 0x7969
[ 0.880000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: PHY 3 available, BMSR = 0x7949
[ 0.890000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: PHY 4 available, BMSR = 0x7949
[ 0.900000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: PHY 5 available, BMSR = 0xffff
[ 0.910000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: PHY 6 available, BMSR = 0xffff
[ 0.920000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Detected AR8337 switch
Best
Christian
Thanks for testing. Seems like PHY's 0, 3 and 4 are there but just not connected to any pin on the chip.
So we have to look for something else to tell a 8334 from a 8337.
The only other difference I found is the initial setting of LED_CTRL3 register.
Could you please test the following patch (first remove the initial patch attempt)?

Rgds, Heiner

PS: I have no datasheet for AR8335 and don't know how LED_CTRL3 is set initially on this chip.
Therefore AR8335 might not work correctly. However no router with this chip is known yet.

---
target/linux/generic/files/drivers/net/phy/ar8216.h | 13 ++++++++++++-
target/linux/generic/files/drivers/net/phy/ar8327.c | 18 +++++++++++++++++-
2 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/target/linux/generic/files/drivers/net/phy/ar8216.h b/target/linux/generic/files/drivers/net/phy/ar8216.h
index 0f53f23..a23c3be 100644
--- a/target/linux/generic/files/drivers/net/phy/ar8216.h
+++ b/target/linux/generic/files/drivers/net/phy/ar8216.h
@@ -405,6 +405,7 @@ struct ar8xxx_priv {
struct mutex reg_mutex;
u8 chip_ver;
u8 chip_rev;
+ u8 chip_subver;
const struct ar8xxx_chip *chip;
void *chip_data;
bool initialized;
@@ -562,11 +563,21 @@ static inline bool chip_is_ar8327(struct ar8xxx_priv *priv)
return priv->chip_ver == AR8XXX_VER_AR8327;
}

-static inline bool chip_is_ar8337(struct ar8xxx_priv *priv)
+static inline bool chip_is_ar833x(struct ar8xxx_priv *priv)
{
return priv->chip_ver == AR8XXX_VER_AR8337;
}

+static inline bool chip_is_ar8334(struct ar8xxx_priv *priv)
+{
+ return chip_is_ar833x(priv) && priv->chip_subver == 4;
+}
+
+static inline bool chip_is_ar8337(struct ar8xxx_priv *priv)
+{
+ return chip_is_ar833x(priv) && priv->chip_subver == 7;
+}
+
static inline void
ar8xxx_reg_set(struct ar8xxx_priv *priv, int reg, u32 val)
{
diff --git a/target/linux/generic/files/drivers/net/phy/ar8327.c b/target/linux/generic/files/drivers/net/phy/ar8327.c
index 07e837e..96f3378 100644
--- a/target/linux/generic/files/drivers/net/phy/ar8327.c
+++ b/target/linux/generic/files/drivers/net/phy/ar8327.c
@@ -621,6 +621,22 @@ static int
ar8327_hw_init(struct ar8xxx_priv *priv)
{
int ret;
+ u32 led_val;
+
+ if (chip_is_ar833x(priv)) {
+ led_val = ar8xxx_read(priv, AR8327_REG_LED_CTRL3);
+ /*
+ * no default LED pattern is set for PHY 1 on AR8334
+ * this code might not work correctly on AR8335
+ */
+ led_val = (led_val & BITS(8, 6)) >> 8;
+ dev_info(&priv->phy->dev, "led_val = %x\n", led_val);
+ if (led_val)
+ priv->chip_subver = 7;
+ else
+ priv->chip_subver = 4;
+ dev_info(&priv->phy->dev, "Detected AR833%d\n", priv->chip_subver);
+ }

priv->chip_data = kzalloc(sizeof(struct ar8327_data), GFP_KERNEL);
if (!priv->chip_data)
@@ -1206,7 +1222,7 @@ const struct ar8xxx_chip ar8337_chip = {
.config_at_probe = true,
.mii_lo_first = true,

- .name = "Atheros AR8337",
+ .name = "Atheros AR833X",
.ports = AR8327_NUM_PORTS,
.vlans = AR8X16_MAX_VLANS,
.swops = &ar8327_sw_ops,
--
2.3.5
Christian Mehlis
2015-04-28 12:15:29 UTC
Permalink
Post by Heiner Kallweit
The only other difference I found is the initial setting of LED_CTRL3 register.
Could you please test the following patch (first remove the initial patch attempt)?
[ 0.850000] switch0: Atheros AR833X rev. 2 switch registered on
ag71xx-mdio.0
[ 0.860000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: led_val = 3f
[ 0.860000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Detected
AR8337

It seems that we have no luck here...
In case you have any new idea I'll test the patch.

Here is a picture of the switch chip:
Loading Image...

Best
Christian
Kathy Giori
2015-04-28 16:04:45 UTC
Permalink
Post by Heiner Kallweit
The only other difference I found is the initial setting of LED_CTRL3 register.
Could you please test the following patch (first remove the initial patch attempt)?
[ 0.850000] switch0: Atheros AR833X rev. 2 switch registered on ag71xx-mdio.0
[ 0.860000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: led_val = 3f
[ 0.860000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Detected
AR8337
It seems that we have no luck here...
In case you have any new idea I'll test the patch.
Here's some general info about the QCA8334 chip that might help. If
you have specific questions let me know and I will try to find
answers.

The four ports of the Gigabit switch engine are:
Port 0 GMAC: RGMII/MII/RMII
Port 2 and 3 GMAC: 2 *10/100/1000BASE-T
Port 6 GMAC: SerDes/SGMII

It can be configured using serial EEPROM and/or the MDC/MDIO interface.

kg
Heiner Kallweit
2015-04-28 18:37:46 UTC
Permalink
Post by Heiner Kallweit
The only other difference I found is the initial setting of LED_CTRL3 register.
Could you please test the following patch (first remove the initial patch attempt)?
[ 0.850000] switch0: Atheros AR833X rev. 2 switch registered on ag71xx-mdio.0
[ 0.860000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: led_val = 3f
[ 0.860000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Detected AR8337
It seems that we have no luck here...
In case you have any new idea I'll test the patch.
http://c33.imgup.net/2015-04-166a5b.jpg
Best
Christian
.
I found a datasheet for QCA8334 and according to it these bits in LED_CTRl3 are supposed to
be 0 for this chip. But this doesn't seem to be true ..
Meanwhile I'm running out of ideas how to tell between the two chips.

However I have another hypothesis:
The drivers sets bit MAC06_EXCHANGE_EN for AR8337. According to the datasheet this means
"Exchange MAC0 and MAC6". My assumption is that MAC6 is used as CPU port if this bit is set.
Having said this whether to set this bit or not might not be chip-specific but board-specific
(CPU connected to MAC0 vs. MAC6 pins of the switch chip).
AR8334 has no MAC6 (R)GMII pins therefore this bit must not be set.
Not sure how many supported devices actually use an AR8337. Maybe they share some
reference design and use MAC6 in general?
Conclusion would be that the driver can not know whether to set the bit or not. It would
have to be defined in platform configuration or device tree.

I'm not an expert and refactored few parts of the driver only.
Therefore I can not promise any quick results, however I'll have a look at it.

Rgds, Heiner
Heiner Kallweit
2015-04-28 20:10:59 UTC
Permalink
Post by Heiner Kallweit
Post by Heiner Kallweit
The only other difference I found is the initial setting of LED_CTRL3 register.
Could you please test the following patch (first remove the initial patch attempt)?
[ 0.850000] switch0: Atheros AR833X rev. 2 switch registered on ag71xx-mdio.0
[ 0.860000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: led_val = 3f
[ 0.860000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Detected AR8337
It seems that we have no luck here...
In case you have any new idea I'll test the patch.
http://c33.imgup.net/2015-04-166a5b.jpg
Best
Christian
.
I found a datasheet for QCA8334 and according to it these bits in LED_CTRl3 are supposed to
be 0 for this chip. But this doesn't seem to be true ..
Meanwhile I'm running out of ideas how to tell between the two chips.
The drivers sets bit MAC06_EXCHANGE_EN for AR8337. According to the datasheet this means
"Exchange MAC0 and MAC6". My assumption is that MAC6 is used as CPU port if this bit is set.
Having said this whether to set this bit or not might not be chip-specific but board-specific
(CPU connected to MAC0 vs. MAC6 pins of the switch chip).
AR8334 has no MAC6 (R)GMII pins therefore this bit must not be set.
Not sure how many supported devices actually use an AR8337. Maybe they share some
reference design and use MAC6 in general?
Conclusion would be that the driver can not know whether to set the bit or not. It would
have to be defined in platform configuration or device tree.
I'm not an expert and refactored few parts of the driver only.
Therefore I can not promise any quick results, however I'll have a look at it.
Rgds, Heiner
It was easier than I thought, here comes the related patch.

Known limitations:
1. The patch supports configuration of this bit for platform-data-configured
platforms only. DT-based platforms would need a similar extension.
2. For now it's for WPJ344 only. Every other AR8334-based device would need the same
extension to the platform data.

Rgds, Heiner

---
target/linux/ar71xx/files/arch/mips/ath79/mach-wpj344.c | 1 +
target/linux/generic/files/drivers/net/phy/ar8327.c | 5 ++++-
target/linux/generic/files/include/linux/ar8216_platform.h | 4 +++-
3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-wpj344.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-wpj344.c
index fd718bd..590778e 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-wpj344.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-wpj344.c
@@ -98,6 +98,7 @@ static struct ar8327_pad_cfg wpj344_ar8327_pad0_cfg = {
.rxclk_delay_en = true,
.txclk_delay_sel = AR8327_CLK_DELAY_SEL1,
.rxclk_delay_sel = AR8327_CLK_DELAY_SEL2,
+ .mac06_exchange_en = -1,
};

static struct ar8327_led_cfg wpj344_ar8327_led_cfg = {
diff --git a/target/linux/generic/files/drivers/net/phy/ar8327.c b/target/linux/generic/files/drivers/net/phy/ar8327.c
index 07e837e..772d03f 100644
--- a/target/linux/generic/files/drivers/net/phy/ar8327.c
+++ b/target/linux/generic/files/drivers/net/phy/ar8327.c
@@ -124,6 +124,9 @@ ar8327_get_pad_cfg(struct ar8327_pad_cfg *cfg)
break;
}

+ if (cfg->mac06_exchange_en == 1)
+ t |= AR8337_PAD_MAC06_EXCHANGE_EN;
+
return t;
}

@@ -508,7 +511,7 @@ ar8327_hw_config_pdata(struct ar8xxx_priv *priv,
data->port6_status = ar8327_get_port_init_status(&pdata->port6_cfg);

t = ar8327_get_pad_cfg(pdata->pad0_cfg);
- if (chip_is_ar8337(priv))
+ if (chip_is_ar8337(priv) && pdata->pad0_cfg->mac06_exchange_en == 0)
t |= AR8337_PAD_MAC06_EXCHANGE_EN;

ar8xxx_write(priv, AR8327_REG_PAD0_MODE, t);
diff --git a/target/linux/generic/files/include/linux/ar8216_platform.h b/target/linux/generic/files/include/linux/ar8216_platform.h
index 4935ad3..821ff27 100644
--- a/target/linux/generic/files/include/linux/ar8216_platform.h
+++ b/target/linux/generic/files/include/linux/ar8216_platform.h
@@ -47,6 +47,8 @@ struct ar8327_pad_cfg {
bool sgmii_delay_en;
enum ar8327_clk_delay_sel txclk_delay_sel;
enum ar8327_clk_delay_sel rxclk_delay_sel;
+ /* 0 = use driver default -1 = disable 1 = enable */
+ int mac06_exchange_en;
};

enum ar8327_port_speed {
@@ -128,4 +130,4 @@ struct ar8327_platform_data {
const struct ar8327_led_info *leds;
};

-#endif /* AR8216_PLATFORM_H */
\ No newline at end of file
+#endif /* AR8216_PLATFORM_H */
--
2.3.5
Christian Mehlis
2015-04-29 09:26:00 UTC
Permalink
Post by Heiner Kallweit
It was easier than I thought, here comes the related patch.
1. The patch supports configuration of this bit for platform-data-configured
platforms only. DT-based platforms would need a similar extension.
2. For now it's for WPJ344 only. Every other AR8334-based device would need the same
extension to the platform data.
Rgds, Heiner
Hi Heiner,

this explicit way to talk to the driver is working!
Thank you for your effort!

Tested-By: Christian Mehlis <***@m3hlis.de>

##########################################################

Perhaps you know the answer to my last problem with this hardware too:

On plug/unplug I get those events:

[ 25.120000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Port 2 is up
[ 37.130000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Port 2 is down

but the linux network stack is keeping the interface UP.

config interface 'wan'
option ifname 'eth0.2'
option proto 'dhcp'

config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'

config switch_vlan
option device 'switch0'
option vlan '1'
option ports '0t 3'

config switch_vlan
option device 'switch0'
option vlan '2'
option ports '0t 2'

I have never had this behaviour on other platforms...do you think the
compex-344 specific initialization is done wrong?

#########################################################

Best
Christian
Heiner Kallweit
2015-04-29 09:41:42 UTC
Permalink
Post by Christian Mehlis
[ 25.120000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Port 2 is up
[ 37.130000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Port 2 is down
but the linux network stack is keeping the interface UP.
IMHO that's no contradiction. If the port is disconnected the
interface should no longer be LOWER_UP.
UP just means it's enabled, not necessarily connected.

Rgds, Heiner
Christian Mehlis
2015-04-29 14:16:50 UTC
Permalink
Post by Heiner Kallweit
It was easier than I thought, here comes the related patch.
do you plan to send this as a patch to make the change available for
everyone, or should I?

Best
Christian
Heiner Kallweit
2015-04-29 14:44:06 UTC
Permalink
I still have to adjust it to make handling of the new platform
parameter more consistent with general handling of platform data.
Most likely I can submit the final patch by today.

Rgds, Heiner
Post by Christian Mehlis
Post by Heiner Kallweit
It was easier than I thought, here comes the related patch.
do you plan to send this as a patch to make the change available for
everyone, or should I?
Best
Christian
Continue reading on narkive:
Loading...