[OpenWrt-Devel] Autoneg problems with ar8216 on kernel 3.14 (related to ticket 17800)

Heiner Kallweit hkallweit1 at gmail.com
Tue Oct 28 16:55:50 EDT 2014


Regarding point 2 I checked the change history of ar8216.c
With change set 36050 the start code for AR8327 was moved
from config_init to probe.

Commit comment:
"generic: ar8216: start AR8327 switch from the probe routine
The AR8327 switch gets its configuration from platform
data or from the device-tree. This allows to start it
from the probe routine. Doing so makes it usable with
ethernet drivers which only connects to the PHY device
when the ethernet interface is opened."

However I'm not able to say whether this is still relevant or
whether it would be worth a thought to move back the start to
config_init.

Rgds, Heiner


Am 28.10.2014 um 19:41 schrieb Heiner Kallweit:
> 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 at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel



More information about the openwrt-devel mailing list