Message-ID: <C89EFD3CD56F64468D3D206D683A8D22039FFE39@ldam-msx2.fugro-nl.local>
Date:	Thu, 6 Nov 2014 15:01:56 +0100
From:	"Stam, Michel [FINT]" <M.Stam@...ro.nl>
To:	"Charles Keepax" <ckeepax@...nsource.wolfsonmicro.com>
Cc:	"Riku Voipio" <riku.voipio@....fi>, <freddy@...x.com.tw>,
	<davem@...emloft.net>, <linux-usb@...r.kernel.org>,
	<netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<linux-samsung-soc@...r.kernel.org>
Subject: RE: "asix: Don't reset PHY on if_up for ASIX 88772" breaks net onarndale platform

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@...nsource.wolfsonmicro.com] 
Sent: Thursday, November 06, 2014 13:47 PM
To: Stam, Michel [FINT]
Cc: Riku Voipio; freddy@...x.com.tw; davem@...emloft.net;
linux-usb@...r.kernel.org; netdev@...r.kernel.org;
linux-kernel@...r.kernel.org; linux-samsung-soc@...r.kernel.org
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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists