After a little more thinking about it and looking at the code I basically have two questions:
1. Is it actually needed to exclude certain phy's in ar8xxx_phy_config_aneg? (At least for AR8327 it doesn't get called with an addr != 0 anyway) Else we could remove ar8xxx_phy_config_aneg and directly register genphy_config_aneg as callback for autoneg configuration. 2. Call sequence with regard to ar8216 is: ar8216: ar8xxx_phy_probe phy: phy_attach_direct phy: phy_init_hw ar8216: ar8xxx_phy_config_init ar8216: ar8xxx_phy_config_aneg ar8216 driver handles AR8327/AR8337 different from the other supported switch types. ar8xxx_start incl. more detailed configuration is called from ar8xxx_phy_probe already. For the other switch types it's called from ar8xxx_phy_config_init. I wonder whether doing detailed configuration in the probe stage might be too early. phy_init_hw resets the switch anyway later. Doing the detailed setup in ar8xxx_phy_config_init seems to be more suited however there might be good reason why it's handled the way it is. Rgds, Heiner Am 27.10.2014 um 22:00 schrieb Heiner Kallweit: > With two different TPLINK routers (both with a AR8327N switch) I faced the > issue that with > kernel 3.14 certain switch ports used 10MBit/half only. > Under kernel 3.10 everything was fine and the same ports used 1000MBit/full. > > As the ar8216 driver is the same I had a look at the common phy code in > drivers/net/phy. > In function phy_init_hw in phy_device.c kernel 3.14 resets the phy whilst > 3.10 does not. > > The issue turned out to be that when resetting only flag BMCR_RESET is set, > not BMCR_ANENABLE. > (In ar8216.c always both flags are set when the switch is reset) > Therefore autoneg was not enabled. Also later in the boot process it doesn't > get enabled. > Adding BMCR_ANENABLE solved the problem and now also under 3.14 all ports use > 1000MBit/full. > > However I'm not sure whether it's a poper fix to add BMCR_ANENABLE in this > generic phy function. > It might not be appropriate for other phy's. > > After resetting the switch later in the boot process ar8xxx_phy_config_aneg > is called with > phydev->addr being 0. > In this case the function returns immediately. Otherwise it would call > genphy_config_aneg. > Calling genphy_config_aneg would also solve the problem as it checks for > BMCR_ANENABLE > being set and sets it if needed. > I don't know the reason why genphy_config_aneg isn't called in case of addr 0. > Or is this a typo and the check actually should be addr != 0 ? > > Rgds, Heiner > _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
