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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <C89EFD3CD56F64468D3D206D683A8D22039FFE16@ldam-msx2.fugro-nl.local>
Date:	Thu, 6 Nov 2014 13:39:07 +0100
From:	"Stam, Michel [FINT]" <M.Stam@...ro.nl>
To:	"Riku Voipio" <riku.voipio@....fi>,
	"Charles Keepax" <ckeepax@...nsource.wolfsonmicro.com>
Cc:	<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 on arndale platform

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:riku.voipio@....fi] 
Sent: Thursday, November 06, 2014 13:04 PM
To: Charles Keepax
Cc: Riku Voipio; Stam, Michel [FINT]; 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
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 <riku.voipio@...aro.org>

> --- 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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html