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?). Kind regards, Michel Stam -----Original Message----- From: Charles Keepax [mailto:ckeepax@xxxxxxxxxxxxxxxxxxxxxxxxxxx] Sent: Thursday, November 06, 2014 13:47 PM To: Stam, Michel [FINT] Cc: Riku Voipio; freddy@xxxxxxxxxxx; davem@xxxxxxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux-samsung-soc@xxxxxxxxxxxxxxx Subject: Re: "asix: Don't reset PHY on if_up for ASIX 88772" breaks net onarndale platform On Thu, Nov 06, 2014 at 01:39:07PM +0100, Stam, Michel [FINT] wrote: > Hello Riku and Charles, > > I tried this with my original patch and the suggested patch applied, > this seems to work for me too. > > One thing that bothers me, is the suspend / resume situation; usbnet.c > seems to call the bind( ) on probe( ). Suspend / resume do not seem to > call bind( ) directly. > > As Riku pointed out, the original patch I reverted was because of > suspend/resume issues. I wonder if this will still work? I seem to remember I had a few issues with Arndale suspend and resume last time I tried it anyways, so not sure I will be able to test for that. But I will have a go. But in either case I guess a fix for that is probably orthogonal to my suggested fix here, as it looks pretty clear we intended to fully reset the device in bind and were appartently not doing that. So this patch is probably a needed fix anyway. Even if there are seperate issues relating to suspend and resume. Thanks, Charles -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |