<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 28, 2014 at 12:15 PM, Jonas Gorski <span dir="ltr"><<a href="mailto:jogo@openwrt.org" target="_blank">jogo@openwrt.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb adM"><div class="">On Fri, Nov 28, 2014 at 11:06 AM, Heiner Kallweit <<a href="mailto:hkallweit1@gmail.com">hkallweit1@gmail.com</a>> wrote:<br>
> In my tests with AR8327 this callback was never called with an addr != 0.<br>
> Seems logical to me as it's called for the PHY attached to the net device<br>
> only.<br>
><br>
> In most cases this is addr 0, just for AR8316 with port4_phy being set this<br>
> could be 4.<br>
><br>
> This leads to two questions:<br>
><br>
> 1. The current version of this function checks for "addr == 0" always, I'd<br>
> assume this is not correct for AR8316 and port4_phy being set.<br>
><br>
> 2. As it seems to be called for the attached PHY addr only and in exactly<br>
> this case we do nothing: Can we simply replace this callback with a dummy<br>
> "return 0" ?<br>
<br>
</div></div>Port4_phy being set means the switch operates in dual-mii mode.<br>
<br>
Most Atheros switches (including AR8327) support a dual-phy mode,<br>
where port 5 / phy 4 is split out from the rest of the switch and used<br>
as a single phy for a second ethernet mac. In these cases phy 4 is<br>
used like a standard phy, and the kernel needs to be able to configure<br>
autonegotiation or other features.<br>
<br>
Consequently you will only see the callback being called for addr != 0<br>
if the switch is in this mode and there is a second ethernet mac as<br>
the single wan port. I'm not sure if there are any OpenWrt supported<br>
devices with this setup with AR8327, but there are several examples<br>
for AR8316, e.g. the RouterStation Pro [1].<br>
<br>
The switch driver claiming phy 0 is technically wrong, as the<br>
connection to the switch isn't using phy 0, but uses a fixed (R)(G)MII<br>
connection that does not support autonegotiation. But there also is no<br>
other phy address on the MDIO bus which represents the cpu port, so we<br>
need this workaround for autodetection/-attachment.<br>
<br>