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

Commit Message

Charles Keepax Nov. 6, 2014, 10:01 a.m. UTC

On Thu, Nov 06, 2014 at 11:06:51AM +0200, Riku Voipio wrote:
> On Wed, Nov 05, 2014 at 03:02:58PM +0000, Charles Keepax wrote:
> > On Wed, Nov 05, 2014 at 01:04:37PM +0100, Stam, Michel [FINT] wrote:
> > > Hello Charles,
> > > 
> > > After looking around I found the reset value for the 8772 chip, which
> > > seems to be 0x1E1 (ANAR register).
> > > 
> > > This equates to (according to include/uapi/linux/mii.h)
> > > ADVERTISE_ALL | ADVERTISE_CSMA.
> > > 
> > > The register only seems to become 0 if the software reset fails.
>  
> > Odd it definitely reads back as zero on Arndale. I am guessing
> > that the root of the problem here is that for some reason Arndale
> > POR of the ethernet is pants and it needs a full software reset
> > before it will work and the patch removes the full reset
> > callback.
> 
> The asix on arndale comes semi-configured from u-boot, which I guess is
> not the state kernel expects it to come in. At least in my case where
> I use tftp from u-boot to load my kernel.
> 
> So probably the full reset is needed here to make the asix chip come
> to a truly pristine state.
> 
> The commit that Michel partially reverted (by returning to use
> ax88772_link_reset instead of ax88772_reset), indicates that a strong reset
> is needed for suspend/resume as well:

Ok I think I have cracked this one. I am pretty sure you are
right that the USB comes to us in a strange state and needs
a full reset, but that only needs to happen once when the driver
is bound in. So there is some code in ax88772_bind that appears
to try to reset the device but does a lot less than ax88772_reset
and I think that must be the problem. Applying the following on
top of the patch we have been debating I think will make
everything work for all of us:

send in a proper patch if it looks good.

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Riku Voipio Nov. 6, 2014, 12:04 p.m. UTC | #1

On Thu, Nov 06, 2014 at 10:01:04AM +0000, Charles Keepax wrote:
> On Thu, Nov 06, 2014 at 11:06:51AM +0200, Riku Voipio wrote:
> > The asix on arndale comes semi-configured from u-boot, which I guess is
> > not the state kernel expects it to come in. At least in my case where
> > I use tftp from u-boot to load my kernel.
> > 
> > So probably the full reset is needed here to make the asix chip come
> > to a truly pristine state.
> > 
> > The commit that Michel partially reverted (by returning to use
> > ax88772_link_reset instead of ax88772_reset), indicates that a strong reset
> > is needed for suspend/resume as well:
 
> Ok I think I have cracked this one. I am pretty sure you are
> right that the USB comes to us in a strange state and needs
> a full reset, but that only needs to happen once when the driver
> is bound in. So there is some code in ax88772_bind that appears
> to try to reset the device but does a lot less than ax88772_reset
> and I think that must be the problem. Applying the following on
> top of the patch we have been debating I think will make
> everything work for all of us:

The patch below on top of 3.18-rc3 fixes arndale network for me.

Tested-by: Riku Voipio <[e-mail]>

> --- a/drivers/net/usb/asix_devices.c
> +++ b/drivers/net/usb/asix_devices.c
> @@ -465,19 +465,7 @@ static int ax88772_bind(struct usbnet *dev,
> struct usb_interface *in
>                 return ret;
>         }
> 
> -       ret = asix_sw_reset(dev, AX_SWRESET_IPPD | AX_SWRESET_PRL);
> -       if (ret < 0)
> -               return ret;
> -
> -       msleep(150);
> -
> -       ret = asix_sw_reset(dev, AX_SWRESET_CLEAR);
> -       if (ret < 0)
> -               return ret;
> -
> -       msleep(150);
> -
> -       ret = asix_sw_reset(dev, embd_phy ? AX_SWRESET_IPRL : AX_SWRESET_PRTE);
> +       ax88772_reset(dev);
> 
> If you guys could test that and let me know how you get on I will
> send in a proper patch if it looks good.
> 
> Thanks,
> Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Stam, Michel [FINT] Nov. 6, 2014, 12:39 p.m. UTC | #2

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? 

Kind regards,

Michel Stam

-----Original Message-----
From: Riku Voipio [mailto:[e-mail]] 
Sent: Thursday, November 06, 2014 13:04 PM
To: Charles Keepax
Cc: Riku Voipio; Stam, Michel [FINT]; [e-mail];
[e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]
Subject: Re: "asix: Don't reset PHY on if_up for ASIX 88772" breaks net
on arndale platform

On Thu, Nov 06, 2014 at 10:01:04AM +0000, Charles Keepax wrote:
> On Thu, Nov 06, 2014 at 11:06:51AM +0200, Riku Voipio wrote:
> > The asix on arndale comes semi-configured from u-boot, which I guess

> > is not the state kernel expects it to come in. At least in my case 
> > where I use tftp from u-boot to load my kernel.
> > 
> > So probably the full reset is needed here to make the asix chip come

> > to a truly pristine state.
> > 
> > The commit that Michel partially reverted (by returning to use 
> > ax88772_link_reset instead of ax88772_reset), indicates that a 
> > strong reset is needed for suspend/resume as well:
 
> Ok I think I have cracked this one. I am pretty sure you are right 
> that the USB comes to us in a strange state and needs a full reset, 
> but that only needs to happen once when the driver is bound in. So 
> there is some code in ax88772_bind that appears to try to reset the 
> device but does a lot less than ax88772_reset and I think that must be

> the problem. Applying the following on top of the patch we have been 
> debating I think will make everything work for all of us:

The patch below on top of 3.18-rc3 fixes arndale network for me.

Tested-by: Riku Voipio <[e-mail]>

> --- a/drivers/net/usb/asix_devices.c
> +++ b/drivers/net/usb/asix_devices.c
> @@ -465,19 +465,7 @@ static int ax88772_bind(struct usbnet *dev, 
> struct usb_interface *in
>                 return ret;
>         }
> 
> -       ret = asix_sw_reset(dev, AX_SWRESET_IPPD | AX_SWRESET_PRL);
> -       if (ret < 0)
> -               return ret;
> -
> -       msleep(150);
> -
> -       ret = asix_sw_reset(dev, AX_SWRESET_CLEAR);
> -       if (ret < 0)
> -               return ret;
> -
> -       msleep(150);
> -
> -       ret = asix_sw_reset(dev, embd_phy ? AX_SWRESET_IPRL :
AX_SWRESET_PRTE);
> +       ax88772_reset(dev);
> 
> If you guys could test that and let me know how you get on I will send

> in a proper patch if it looks good.
> 
> Thanks,
> Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Charles Keepax Nov. 6, 2014, 12:46 p.m. UTC | #3

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 [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Stam, Michel [FINT] Nov. 6, 2014, 2:01 p.m. UTC | #4

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:[e-mail]] 
Sent: Thursday, November 06, 2014 13:47 PM
To: Stam, Michel [FINT]
Cc: Riku Voipio; [e-mail]; [e-mail];
[e-mail]; [e-mail];
[e-mail]; [e-mail]
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 [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Charles Keepax Nov. 6, 2014, 2:09 p.m. UTC | #5

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
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Riku Voipio Nov. 7, 2014, 8:44 a.m. UTC | #6

On Thu, Nov 06, 2014 at 02:09:40PM +0000, Charles Keepax wrote:
> 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 for digging through,

Make sure the commit message is clear that your patch is a regression
fix - following just this thread it might be a bit unclear.

Riku

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -465,19 +465,7 @@  static int ax88772_bind(struct usbnet *dev,
struct usb_interface *in
                return ret;
        }

-       ret = asix_sw_reset(dev, AX_SWRESET_IPPD | AX_SWRESET_PRL);
-       if (ret < 0)
-               return ret;
-
-       msleep(150);
-
-       ret = asix_sw_reset(dev, AX_SWRESET_CLEAR);
-       if (ret < 0)
-               return ret;
-
-       msleep(150);
-
-       ret = asix_sw_reset(dev, embd_phy ? AX_SWRESET_IPRL : AX_SWRESET_PRTE);
+       ax88772_reset(dev);

If you guys could test that and let me know how you get on I will