[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <C89EFD3CD56F64468D3D206D683A8D2203863DD8@ldam-msx2.fugro-nl.local>
Date: Mon, 29 Sep 2014 15:45:56 +0200
From: "Stam, Michel [FINT]" <M.Stam@...ro.nl>
To: <netdev@...r.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
Download attachment "0001-Don-t-reset-PHY-on-if_up-for-ASIX-88772.patch" of type "application/octet-stream" (1252 bytes)
Powered by blists - more mailing lists