Re: "asix: Don't reset PHY on if_up for ASIX 88772" breaks net onarndale platform

[Charles Keepax <ckeepax@opensource.wolfsonmicro.com>]

On Thu, Nov 06, 2014 at 03:01:56PM +0100, Stam, Michel [FINT] wrote:
> Hello Charles and Riku,
> 
> I've quickly tested this on a 3.10 kernel i had around;
> I enabled CONFIG_PM, CONFIG_PM_RUNTIME, CONFIG_PM_AUTOSLEEP,
> CONFIG_SUSPEND, CONFIG_SUSPEND_FREEZER, CONFIG_FREEZER in the kernel (by
> default they are disabled for our setup, I enabled anything regarded to
> runtime powermanagement to be sure I would trigger suspend/resume).
> 
> Then:
> cd /sys/bus/usb/devices/1-2/power
> echo auto > control
> echo 1 > autosuspend
> echo 0 > autosuspend_delay_ms
> echo enabled > wakeup
> 
> # make sure there's no processes routing traffic over the eth1 interface
> 
> ifconfig eth1 down
> sleep 4 # sleep some arbitrary long time
> ifconfig eth1 up
> 
> check dmesg; it will reset back to 100 Mbps/full duplex.
> 
> This confirms that the suspend / resume does not work well. So long as
> the suspend is not triggered, it does seem to work, though. I cannot say
> whether the original issue that triggered this is still around; the ASIX
> chip setup we use is soldered to the PCB and hooked up to a fixed device
> on-board. 
> I also tried to ping the device on the other side of the ASIX chip after
> the suspend/resume cycle, I could not ping it. I cannot conclusively say
> that this is due to the ASIX driver, as the device on the other side
> does not like switching PHY speeds (it may go into a non-responsive
> state). It is for this reason that we run it at half duplex/ 10Mbps at
> all times.
> 
> As said; we are not using this kind of power management, so it does not
> raise any issues for us. I am merely pointing out that this may need
> work (in the future?).

Cool thanks for checking this I will make a note in the commit
message that suspend/resume might need some more work.

Thanks,
Charles