ASIX 88772

ASIX 88772

[Stam, Michel [FINT]]

[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]

Dear list,

A while back we did an upgrade of the firmware running on our embedded
devices. These devices, amongst others, use an ASIX chip, model 88772A.

What we noticed, was that ethtool settings would be negated when the
interface was set to 'up'. This, effectively voided any control we tried
to exercise over the autonegotiation process (it always returns back to
100 Mbps/Full duplex). After comparing with the kernel we used before
(we used 2.6.22 before, now 3.10.34), I discovered that the difference
was the .link_reset function pointer defined in the driver_info struct
in drivers/net/usb/asix_devices.c:888. By setting it back to its
previous value, ax88772_link_reset, the functionality is restored and
ethtool behaves as expected.

Apparently this change to drivers/net/usb/asix_devices.c happened at
line 888 as part of commit 2e55cc721, which moved the driver into its
own file with that commit. It apparently also addresses some link reset
problems.

Would anyone have any idea what kind of link reset problems these were?

I have attached a git format-patch which works for us, but I would like
to make sure it does not break other devices instead. I've attached it
to this email because the mail client seems to corrupt the patches
occasionally.

Best regards,

Michel Stam

[-- Attachment #2: 0001-Don-t-reset-PHY-on-if_up-for-ASIX-88772.patch --]
[-- Type: application/octet-stream, Size: 1252 bytes --]

From feb298ea0b5733bcbc3171c6c477f55d6fe9cdcf Mon Sep 17 00:00:00 2001
From: Michel Stam <m.stam@fugro.nl>
Date: Tue, 23 Sep 2014 17:20:23 +0200
Subject: [PATCH] Don't reset PHY on if_up for ASIX 88772

I've noticed every time the interface is set to 'up,', the kernel
reports that the link speed is set to 100 Mbps/Full Duplex, even
when ethtool is used to set autonegotiation to 'off', half
duplex, 10 Mbps.
It can be tested by:
 ifconfig eth0 down
 ethtool -s eth0 autoneg off speed 10 duplex half
 ifconfig eth0 up

Then checking 'dmesg' for the link speed.

Signed-off-by: Michel Stam <m.stam@fugro.nl>
---
 drivers/net/usb/asix_devices.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index 5d19409..2c05f6c 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -890,7 +890,7 @@ static const struct driver_info ax88772_info = {
 	.unbind = ax88772_unbind,
 	.status = asix_status,
 	.link_reset = ax88772_link_reset,
-	.reset = ax88772_reset,
+	.reset = ax88772_link_reset,
 	.flags = FLAG_ETHER | FLAG_FRAMING_AX | FLAG_LINK_INTR | FLAG_MULTI_PACKET,
 	.rx_fixup = asix_rx_fixup_common,
 	.tx_fixup = asix_tx_fixup,
-- 
1.7.12.1

RE: ASIX 88772

[Stam, Michel [FINT]]

LS,

Is it possible for someone to apply this patch?

Best regards,

Michel Stam

-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
On Behalf Of Stam, Michel [FINT]
Sent: Monday, September 29, 2014 15:46 PM
To: netdev@vger.kernel.org
Subject: ASIX 88772

Dear list,

A while back we did an upgrade of the firmware running on our embedded
devices. These devices, amongst others, use an ASIX chip, model 88772A.

What we noticed, was that ethtool settings would be negated when the
interface was set to 'up'. This, effectively voided any control we tried
to exercise over the autonegotiation process (it always returns back to
100 Mbps/Full duplex). After comparing with the kernel we used before
(we used 2.6.22 before, now 3.10.34), I discovered that the difference
was the .link_reset function pointer defined in the driver_info struct
in drivers/net/usb/asix_devices.c:888. By setting it back to its
previous value, ax88772_link_reset, the functionality is restored and
ethtool behaves as expected.

Apparently this change to drivers/net/usb/asix_devices.c happened at
line 888 as part of commit 2e55cc721, which moved the driver into its
own file with that commit. It apparently also addresses some link reset
problems.

Would anyone have any idea what kind of link reset problems these were?

I have attached a git format-patch which works for us, but I would like
to make sure it does not break other devices instead. I've attached it
to this email because the mail client seems to corrupt the patches
occasionally.

Best regards,

Michel Stam

Re: ASIX 88772

[Christian Riesch]

Hi Michel,

On Thu, Oct 2, 2014 at 9:50 AM, Stam, Michel [FINT] <M.Stam@fugro.nl> wrote:
> LS,
>
> Is it possible for someone to apply this patch?

Patches must be sent in the email body, not as an attachment. Please
use git send-email to send the patch, other mail clients will most
likely break the patch as you already noted. Please send the patch
again.

You should also take the authors of the patch that made the change
(4ad1438f) that you would like to revert on cc, Freddy Xin
<freddy@asix.com.tw> and Grant Grundler <grundler@chromium.org> in
this case.

Regards,
Christian