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