AR8327 Virtual Cable Test

For Developers
1

Hey All,

I've been trying to get the Virtual Cable Test working on an AR8327 switch, but so far, no panache. I can read the registers, but I'm getting not very sensible results.

Question 1: within openwrt/switchdev, the vlan_port maps to the PHY in the end? The number seems to match from that at last.

Question 2: The PHY MII address, is 0 - 5 is for the actual PHY's right? not some offset or anything.

Question 3: Though I'll try this next anyway, After poking the PHY registers, do we need to reset the switch via the BMCR? I know some changes to the PHY's require a PHY reset ...

Question 4: I see in AR8216.h the register 0x0098 as 'MDIO_CTRL' yet in all other datasheets this is called the 'HEADER_CTR" register. I know this chip can be controlled either via MDIO, or by injecting a few bytes into the TCP header. I haven't figured out how this switch chip is controlled exactly, but is it using this header injection? What's more interesting, all other datasheets, put the MDIO control on 0x003c. Is there some offset I missed? All supported chips in the driver use this same register ...

If there's any other thoughts on how to make this work, that would be much appreciated. Even if some vendor firmware offers this functionality. Of course it could be very much so the case, that this feature is simply broken in the PHY. The original firmware of the DUT (WDR4300) doesn't offer this feature in any case. What I have so far:

	mutex_lock(&bus->mdio_lock);
	for (unsigned int i = 0; i < result_len; i++) {
		int val = -EINVAL;
		int reg;

		bus->write(bus, port, 0x16, i << 8 | 1);
		ret = read_poll_timeout(bus->read, val,
			                val == 0, 1000, 100000, true /* false */,
			                bus, port, 0x16);
		if (ret == -ETIMEDOUT)
			goto out;

		reg = bus->read(bus, port, 0x1c);
		pr_err("Reg: 0x%x\n", reg);
};
mutex_unlock(&bus->mdio_lock);
1 Like
2

I'm about to give up on this little endavour unless some 'aha' moment is shared :wink:

It looks like for whatever reason, it's not easily possible to read those extended registers. For example, readin the PHYID works just fine, on all normal ports; but reading the cable test register, just gives some random data, that isn't supposed to be there (datasheet says 'RO, always 0' and it clearly isn't. So am I reading even the right registers? Is there some other magic involved?

	pr_err("%s-%d: test\n", __func__, __LINE__);
	pr_err("ID: 0x%x %x\n", mdiobus_read(bus, port, MII_PHYSID1), mdiobus_read(bus, port, MII_PHYSID2));
	pr_err("ID-bus: 0x%x %x\n", bus->read(bus, port, MII_PHYSID1), bus->read(bus, port, MII_PHYSID2));
	pr_err("VCT: 0x%x %x\n", mdiobus_read(bus, port, 0x1c), mdiobus_read(bus, port, 0x16));

The mdiobus_read command obviously works; and reading any of the other MII standard registers works just fine as well ...

3

So, it looks like this chip is somewhat supported in the master QCA8k driver(s). The cable test for this chip I'm tackling is not there, but the registers match up; so it's just a matter of getting master running on this switch.

Since there the ath79 is still on 5.10 it seems; I will help/wait for it to be ported to 5.15 first; so that a switch to master can be done more easily. Maybe 5.15 even already contains the needed bits.

TBC!

1 Like
4

qca8k fully supports the AR8327, however cable testing is a PHY feature.
Internal switch PHY-s are supported by the at803x driver but I don't think that cable testing support was added for these, should be rather similar to AR803x PHY series cable test though

2 Likes
5

I had attempted to start a discussion about cable testing on QCA a while back: Tool for VCT (Virtual Cable Test) for QCA switches and others wanted

6

Thanks for your response @robimarko,

It looks like yes. I haven't been able to do a qca8k build yet, the ath79 platform is still stuck on 5.10 for the time being, but as soon as I can test, we can merge; as I think it's almost just that.

One problem/thing I don't understand is the following else https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/phy/at803x.c#n1541

The pair can't be more then 0 - 3; not only due to the bit-width but also due to the pair array being 4 in size. So what's the point of that 0xf mask? It's worsened by the fact that the if does list which PHY's only are 2 bits wide, but the others are a bit more misterious; which ones are the 3 bit wide PHY's? The small set of atheros datasheets I have, none apply. Funnily enough; the whole pair variable isn't even used for the 'more then 4 pairs' case ...

7

That's exactly what I was trying to resolve as well :slight_smile:
TBC :slight_smile:

8

I am not really familiar with the older AR803x PHY family, only with the newer QCA807x (did cable testing support for it) and QCA808x

9

@robimarko I think that the 0x3 mask IS for the older ones, because all datasheets I have only have 2 bits for the pair (which is logical, pairs A - D :p)

It seems the newer switches may have a different mask; but I haven't gotten any datasheets on those (but I've been lazy to search, well lazy .. I went through all datasheets from here: https://github.com/Deoptim/atheros)

10

The latest AR8033 datasheet also has only 2 bits for pair selection.

11

IMO, best to drop that if alltogether; and if a device has 3 bits (needs 3 bits?) a) a translation is needed anyways and b) better mark those explicitly as?

        if (phydev->phy_id == ATH9331_PHY_ID ||
            phydev->phy_id == ATH8032_PHY_ID ||
+           phydev->phy_id == QCA8327_B_PHY_ID ||
            phydev->phy_id == QCA9561_PHY_ID)
-               pair_mask = 0x3;
+               pair_mask = (AT803X_CDT_MDI_PAIR_MASK >> AT803X_CDT_MDI_PAIR_OFFSET);

is what I have locally; to add the 8327; but instead, that entire 'if' should go (only to be readded to those 0x7 oddballs).

Besides, the function IS called at803x_cable_test_get_status which this logic seems to cover for most switches anyway.

12

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.