So, it turns out that the AR8327 has 7 ports internally:
* GMAC0 / external (CPU) MAC0
* GMAC1 / port1 -> GMAC5 / port5: external switch port PHYs
* GMAC6 / external (CPU) MAC1
Now, depending upon how things are wired up, the second CPU port (MAC1)
can be wired to either the switch (port6), or through port5's PHY, bypassing
the GMAC+switch entirely. Ie, it can pretend to be a boring PHY, saving
system designers from having to include a separate PHY for a "WAN" port.
Here's the rub - the AP135 board (QCA955x SoC) hooks up arge0 to
the second CPU port on the AR8327, but it's hooked up as RGMII.
So, in order to hook it up to the rest of the switch, it isn't configured
as a separate PHY - OpenWRT has it setup as connected via RGMII to
GMAC6 and (I'm guessing) it's set to be a WAN port by configuring up
port-based VLANs or something.
Thus, with a port mask of 0x3f, GMAC6 was never allowed to receive traffic
from any other port. It could transmit fine, but not receive anything.
So, now it works enough for me to continue doing board bootstrapping.
Note, this isn't enough to make the QCA955x + AR8327 work - there's
a bunch of uncommitted work to both the platform SoC (interrupt handling,
ethernet, etc) and the ethernet switch (register access space, setup, etc)
that needs to happen. However, this particular change is also relevant to
other SoCs, like the AR934x and AR7161, both of which can be glued to
this switch.
Tested:
* AP135 development board
TODO:
* Figure out whether I can somehow abuse another port mode to have this
be a pass-through PHY, or whether I should just create some more boot
time hints to explicitly set up port-based isolation so this works
in a more useful way by default.