Le 28/10/2014 11:46, Heiner Kallweit a écrit :
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.
Address 0 is special, since this is a MDIO broadcast address that will
usually be handled by switches as "write to all front-panel ports".
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.
I suppose that you could re-advertise auto-negotiation by calling
genphy_config_advert() in the config_init routine.
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
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
