On 2014-11-19 22:17, Heiner Kallweit wrote: > Am 19.11.2014 um 21:19 schrieb Felix Fietkau: >> On 2014-10-31 21:38, Heiner Kallweit wrote: >>> Kernel 3.14 introduced a switch reset in phy_init_hw in drivers/net/phy >>> causing BMCR_ANENABLE to get cleared. >>> >>> Due to the fact that ar8xxx_phy_config_aneg does nothing for >>> PHY 0 autonegatiation support remains disabled. >>> This can cause ports to operate at 10MBit/half-duplex only. >>> >>> Fix this by calling genphy_config_aneg for PHY 0 too as >>> genphy_config_aneg sets BMCR_ANENABLE if it's not yet set. >>> Fixes: ticket 17800 >>> >>> Signed-off-by: Heiner Kallweit <[email protected]> >> Applied the series with a few minor modifications. >> >> Thanks! >> >> - Felix >> > Great! > Not sure whether you've seen the follow-up on some patches of the series. > > Patch 4: > Nov 1st I submitted a version 2 which simplifies ar8xxx_phy_init > by using ar8xxx_has_gige to determine chip GBit capability instead > of passing this information as a parameter to the function. > > Patch 3/5: > I use my routers w/o VLAN functionality and the patches work fine. > However on Nov 8th Dirk Neukirchen reported a problem that with this > patch series his WAN port stopped working. > I have no idea how this patch series can impact VLAN functionality. > However I provided him with updated patches which fixed the issue. > (included in a mail sent Nov 9th). > Eventually I moved the ANEG fixup code from ar8xxx_phy_config_aneg to > ar8xxx_phy_config_init what seems to be cleaner to me. > That's what we discussed about on Nov 13th/14th. > > Having said that I'm totally fine with patches 1 and 2 being applied. > For patches 3 and 4 I'll provide the final (IMHO) versions to be applied. > Regarding patch 5 I'd be interested in other's opinion whether this > ANEG fixup code better fits into config_init or config_aneg to eventually > decide with which version of the patch to go. Somehow the follow-up versions didn't reach my inbox (except for the two that you just sent me today). Please provide incremental fixes on top of current trunk.
- Felix _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
