The change fixes AX88772_suspend() USB vendor commands failure issues.
Signed-off-by: NAllan Chou <allan@asix.com.tw>
Tested-by: NAllan Chou <allan@asix.com.tw>
Tested-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If usb_submit_urb() called from the open function fails, the following
crash may be observed.

r8152 8-1:1.0 eth0: intr_urb submit failed: -19
...
r8152 8-1:1.0 eth0: v1.08.3
Unable to handle kernel paging request at virtual address 6b6b6b6b6b6b6b7b
pgd = ffffffc0e7305000
[6b6b6b6b6b6b6b7b] *pgd=0000000000000000, *pud=0000000000000000
Internal error: Oops: 96000004 [#1] PREEMPT SMP
...
PC is at notifier_chain_register+0x2c/0x58
LR is at blocking_notifier_chain_register+0x54/0x70
...
Call trace:
[<ffffffc0002407f8>] notifier_chain_register+0x2c/0x58
[<ffffffc000240bdc>] blocking_notifier_chain_register+0x54/0x70
[<ffffffc00026991c>] register_pm_notifier+0x24/0x2c
[<ffffffbffc183200>] rtl8152_open+0x3dc/0x3f8 [r8152]
[<ffffffc000808000>] __dev_open+0xac/0x104
[<ffffffc0008082f8>] __dev_change_flags+0xb0/0x148
[<ffffffc0008083c4>] dev_change_flags+0x34/0x70
[<ffffffc000818344>] do_setlink+0x2c8/0x888
[<ffffffc0008199d4>] rtnl_newlink+0x328/0x644
[<ffffffc000819e98>] rtnetlink_rcv_msg+0x1a8/0x1d4
[<ffffffc0008373c8>] netlink_rcv_skb+0x68/0xd0
[<ffffffc000817990>] rtnetlink_rcv+0x2c/0x3c
[<ffffffc000836d1c>] netlink_unicast+0x16c/0x234
[<ffffffc00083720c>] netlink_sendmsg+0x340/0x364
[<ffffffc0007e85d0>] sock_sendmsg+0x48/0x60
[<ffffffc0007e9c30>] SyS_sendto+0xe0/0x120
[<ffffffc0007e9cb0>] SyS_send+0x40/0x4c
[<ffffffc000203e34>] el0_svc_naked+0x24/0x28

Clean up error handling to avoid registering the notifier if the open
function is going to fail.
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add support for Cypress GX3 SuperSpeed to Gigabit Ethernet
Bridge Controller (Vendor=04b4 ProdID=3610).

Patch verified on x64 linux kernel 4.7.4, 4.8.6, 4.9-rc4 systems
with the Kensington SD4600P USB-C Universal Dock with Power,
which uses the Cypress GX3 SuperSpeed to Gigabit Ethernet Bridge
Controller.

A similar patch was signed-off and tested-by Allan Chou
<allan@asix.com.tw> on 2015-12-01.

Allan verified his similar patch on x86 Linux kernel 4.1.6 system
with Cypress GX3 SuperSpeed to Gigabit Ethernet Bridge Controller.
Tested-by: NAllan Chou <allan@asix.com.tw>
Tested-by: NChris Roth <chris.roth@usask.ca>
Tested-by: NArtjom Simon <artjom.simon@gmail.com>
Signed-off-by: NAllan Chou <allan@asix.com.tw>
Signed-off-by: NChris Roth <chris.roth@usask.ca>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The r8152 driver has been broken since (approx) 3.16.xx
when support was added for hardware RX checksums
on newer chip versions.  Symptoms include random
segfaults and silent data corruption over NFS.

The hardware checksum logig does not work on the VER_02
dongles I have here when used with a slow embedded system CPU.
Google reveals others reporting similar issues on Raspberry Pi.

So, disable hardware RX checksum support for VER_02, and fix
an obvious coding error for IPV6 checksums in the same function.

Because this bug results in silent data corruption,
it is a good candidate for back-porting to -stable >= 3.16.xx.
Signed-off-by: NMark Lord <mlord@pobox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The kalmia_send_init_packet() returns zero or a negative return
code, but gcc has no way of knowing that there cannot be a
positive return code, so it determines that copying the ethernet
address at the end of kalmia_bind() will access uninitialized
data:

drivers/net/usb/kalmia.c: In function ‘kalmia_bind’:
arch/x86/include/asm/string_32.h:78:22: error: ‘*((void *)&ethernet_addr+4)’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
   *((short *)to + 2) = *((short *)from + 2);
                      ^
drivers/net/usb/kalmia.c:138:5: note: ‘*((void *)&ethernet_addr+4)’ was declared here

This warning is harmless, but for consistency, we should make
the check for the return code match what the driver does everywhere
else and just progate it, which then gets rid of the warning.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Check answers from USB stack and avoid re-sending the request
multiple times if the device does not respond.

This fixes the following problem, observed with a probably flaky adapter.

[62108.732707] usb 1-3: new high-speed USB device number 5 using xhci_hcd
[62108.914421] usb 1-3: New USB device found, idVendor=0b95, idProduct=7720
[62108.914463] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[62108.914476] usb 1-3: Product: AX88x72A
[62108.914486] usb 1-3: Manufacturer: ASIX Elec. Corp.
[62108.914495] usb 1-3: SerialNumber: 000001
[62114.109109] asix 1-3:1.0 (unnamed net_device) (uninitialized):
	Failed to write reg index 0x0000: -110
[62114.109139] asix 1-3:1.0 (unnamed net_device) (uninitialized):
	Failed to send software reset: ffffff92
[62119.109048] asix 1-3:1.0 (unnamed net_device) (uninitialized):
	Failed to write reg index 0x0000: -110
...

Since the USB timeout is 5 seconds, and the operation is retried 30 times,
this results in

[62278.180353] INFO: task mtpd:1725 blocked for more than 120 seconds.
[62278.180373]       Tainted: G        W      3.18.0-13298-g94ace9e #1
[62278.180383] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
...
[62278.180957] kworker/2:0     D 0000000000000000     0  5744      2 0x00000000
[62278.180978] Workqueue: usb_hub_wq hub_event
[62278.181029]  ffff880177f833b8 0000000000000046 ffff88017fd00000 ffff88017b126d80
[62278.181048]  ffff880177f83fd8 ffff880065a71b60 0000000000013340 ffff880065a71b60
[62278.181065]  0000000000000286 0000000103b1c199 0000000000001388 0000000000000002
[62278.181081] Call Trace:
[62278.181092]  [<ffffffff8e0971fd>] ? console_conditional_schedule+0x2c/0x2c
[62278.181105]  [<ffffffff8e094f7b>] schedule+0x69/0x6b
[62278.181117]  [<ffffffff8e0972e0>] schedule_timeout+0xe3/0x11d
[62278.181133]  [<ffffffff8daadb1b>] ? trace_timer_start+0x51/0x51
[62278.181146]  [<ffffffff8e095a05>] do_wait_for_common+0x12f/0x16c
[62278.181162]  [<ffffffff8da856a7>] ? wake_up_process+0x39/0x39
[62278.181174]  [<ffffffff8e095aee>] wait_for_common+0x52/0x6d
[62278.181187]  [<ffffffff8e095b3b>] wait_for_completion_timeout+0x13/0x15
[62278.181201]  [<ffffffff8de676ce>] usb_start_wait_urb+0x93/0xf1
[62278.181214]  [<ffffffff8de6780d>] usb_control_msg+0xe1/0x11d
[62278.181230]  [<ffffffffc037d629>] usbnet_write_cmd+0x9c/0xc6 [usbnet]
[62278.181286]  [<ffffffffc03af793>] asix_write_cmd+0x4e/0x7e [asix]
[62278.181300]  [<ffffffffc03afb41>] asix_set_sw_mii+0x25/0x4e [asix]
[62278.181314]  [<ffffffffc03b001d>] asix_mdio_read+0x51/0x109 [asix]
...
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The Quectel EC21 and EC25 need the same "set DTR" request as devices
based on the MDM9230 chipset, but has no USB3 support. Our best guess
is that the "set DTR" functionality depends on chipset and/or
baseband firmware generation. But USB3 is still an optional feature.

Since we cannot enable this unconditionally for all older devices, and
there doesn't appear to be anything we can use in the USB descriptors
to identify these chips, we are forced to use a device specific quirk
flag.
Reported-and-tested-by: NSebastian Sjoholm <sebastian.sjoholm@gmail.com>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Disable ALDPS and EEE to avoid the possible failure when setting the PHY.
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Remove r8153_enable_eee().
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Move the PHY relative settings together to hw_phy_cfg().
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Move enabling PHY to init(), otherwise some other settings may fail.
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Move the following functions forward.

	r8152_mmd_indirect()
	r8152_mmd_read()
	r8152_mmd_write()
	r8152_eee_en()
	r8152b_enable_eee()
	r8153_eee_en()
	r8153_enable_eee()
	r8152b_enable_fc()
	r8153_aldps_en()
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

SOme statements in the driver only served to inform
which functions were entered. Ftrace can do that just as good without
needing memory. Remove the statements.
Signed-off-by: NOliver Neukum <oneukum@suse.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We get a few warnings when building kernel with W=1:
drivers/net/usb/lan78xx.c:1182:6: warning: no previous prototype for 'lan78xx_defer_kevent' [-Wmissing-prototypes]
drivers/net/usb/lan78xx.c:1409:5: warning: no previous prototype for 'lan78xx_nway_reset' [-Wmissing-prototypes]
drivers/net/usb/lan78xx.c:2000:5: warning: no previous prototype for 'lan78xx_set_mac_addr' [-Wmissing-prototypes]
....

In fact, these functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
so this patch marks these functions with 'static'.
Signed-off-by: NBaoyou Xie <baoyou.xie@linaro.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Use a more common logging style

Miscellanea:

o Add pr_fmt to prefix each output message
o Realign arguments
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Macros that end in an underscore are just odd.
Add hso_dbg(level, fmt, ...) and use it everwhere instead.

Several uses had additional unnecessary newlines as the
macro added a newline.  Remove the newline from the macro
and add newlines to each use as appropriate.

Remove now unused D<digit> macros.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add mdix control through ethtool.
Signed-off-by: NWoojung Huh <Woojung.huh@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add STRAP_STATUS defines.
Signed-off-by: NWoojung Huh <Woojung.huh@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The workqueue "pegasus_workqueue" queues a single work item per pegasus
instance and hence it doesn't require execution ordering. Hence,
alloc_workqueue has been used to replace the deprecated
create_singlethread_workqueue instance.

The WQ_MEM_RECLAIM flag has been set to ensure forward progress under
memory pressure since it's a network driver.

Since there are fixed number of work items, explicit concurrency
limit is unnecessary here.
Signed-off-by: NBhaktipriya Shridhar <bhaktipriya96@gmail.com>
Acked-by: NTejun Heo <tj@kernel.org>
Acked-by: NPetko Manolov <petkan@mip-labs.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

check the coding style with checkpatch.pl and fix the warnings and errors.
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

From: Grant Grundler <grundler@chromium.org>

The miii_nway_restart() causes a PHY link change activity and
ax88772_link_reset will be called. link_reset will set
AX_CMD_WRITE_MEDIUM_MODE register correctly.

The asix_write_medium_mode in reset() fills in a default value to the register
which may be different from the negotiation result. So do this first.

Ignore the ret value since it's ignored in XXX_link_reset() functions.
Signed-off-by: NGrant Grundler <grundler@google.com>
Signed-off-by: NRobert Foss <robert.foss@collabora.com>
Tested-by: NRobert Foss <robert.foss@collabora.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

From: Grant Grundler <grundler@chromium.org>

https://lkml.org/lkml/2014/11/11/947

Ben Hutchings is correct. IEEE 802.3 spec section "22.2.4.1.1 Reset" requires
up to 500ms delay. Mitigate the "max" delay by polling the phy until BCM_RESET
bit is clear.
Signed-off-by: NGrant Grundler <grundler@chromium.org>
Signed-off-by: NRobert Foss <robert.foss@collabora.com>
Tested-by: NRobert Foss <robert.foss@collabora.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

From: Allan Chou <allan@asix.com.tw>

The change fixes AX88772x resume failure by
- Restore incorrect AX88772A PHY registers when resetting
- Need to stop MAC operation when suspending
- Need to restart MII when restoring PHY
Signed-off-by: NAllan Chou <allan@asix.com.tw>
Signed-off-by: NRobert Foss <robert.foss@collabora.com>
Tested-by: NRobert Foss <robert.foss@collabora.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

From: Vincent Palatin <vpalatin@chromium.org>

Check the answers from the USB stack and avoid re-sending multiple times
the request if the device has disappeared.
Signed-off-by: NVincent Palatin <vpalatin@chromium.org>
Signed-off-by: NRobert Foss <robert.foss@collabora.com>
Tested-by: NRobert Foss <robert.foss@collabora.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

From: Freddy Xin <freddy@asix.com.tw>

In order to R/W registers in suspend/resume functions, in_pm flags are
added to some functions to determine whether the nopm version of usb
functions is called.

Save BMCR and ANAR PHY registers in suspend function and restore them
in resume function.

Reset HW in resume function to ensure the PHY works correctly.
Signed-off-by: NFreddy Xin <freddy@asix.com.tw>
Signed-off-by: NRobert Foss <robert.foss@collabora.com>
Tested-by: NRobert Foss <robert.foss@collabora.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Check for ethtool_ops structures that are only stored in the ethtool_ops
field of a net_device structure or passed as the second argument to
netdev_set_default_ethtool_ops.  These contexts are declared const, so
ethtool_ops structures that have these properties can be declared as const
also.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct ethtool_ops i@p = { ... };

@ok1@
identifier r.i;
struct net_device e;
position p;
@@
e.ethtool_ops = &i@p;

@ok2@
identifier r.i;
expression e;
position p;
@@
netdev_set_default_ethtool_ops(e, &i@p)

@bad@
position p != {r.p,ok1.p,ok2.p};
identifier r.i;
@@
i@p

@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
 struct ethtool_ops i = { ... };
// </smpl>
Suggested-by: NStephen Hemminger <stephen@networkplumber.org>
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Just return an error upon failure.
Signed-off-by: NOliver Neukum <oneukum@suse.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This fixes the oops discovered by the Umap2 project and Alan Stern.
The intf member needs to be set before the firmware is downloaded.
Signed-off-by: NOliver Neukum <oneukum@suse.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

kmalloc will print enough information in case of failure.
Signed-off-by: NWolfram Sang <wsa-dev@sang-engineering.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

kmalloc will print enough information in case of failure.
Signed-off-by: NWolfram Sang <wsa-dev@sang-engineering.com>
Acked-by: NWoojung Huh <woojung.huh@microchip.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

kmalloc will print enough information in case of failure.
Signed-off-by: NWolfram Sang <wsa-dev@sang-engineering.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The firmware in several ZTE devices (at least the MF823/831/910
modems/mifis) use OS fingerprinting to determine which type of device to
export. In addition, these devices export a REST API which can be used to
control the type of device. So far, on Linux, the devices have been seen as
RNDIS or CDC Ether.

When CDC Ether is used, devices of the same type are, as with RNDIS,
exported with the same, bogus random MAC address. In addition, the devices
(at least on all firmware revisions I have found) use the bogus MAC when
sending traffic routed from external networks. And as a final feature, the
devices sometimes export the link state incorrectly. There are also
references online to several other ZTE devices displaying this behavior,
with several different PIDs and MAC addresses.

This patch tries to improve the handling of ZTE devices by doing the
following:

* Create a new driver_info-struct that is used by ZTE devices that do not
have an explicit entry in the product table. This struct is the same as the
default cdc_ether driver info, but a new bind- and an rx_fixup-function
have been added.

* In the new bind function, we check if we have read a random MAC from the
device. If we have, then we generate a new random MAC address. This will
ensure that all devices get a unique MAC.

* The rx_fixup-function replaces the destination MAC address in the skb
with that of the device. I have not seen a revision of these devices that
behaves correctly (i.e., sets the right destination MAC), so I chose not to
do any comparison with for example the known, bogus addresses.

* The MF823/MF832/MF910 sometimes export cdc carrier on twice on connect
(the correct behavior is off then on). Work around this by manually setting
carrier to off if an on-notification is received and the NOCARRIER-bit is
not set.

This change will affect all devices, but it should take care of similar
mistakes made by other manufacturers. I tried to think of/look/test for
problems/regressions that could be introduced by this behavior, but could
not find any. However, my familiarity with this code path is not that
great, so there could be something I have overlooked.

I have tested this patch with multiple revisions of all three devices, and
they behave as expected. In other words, they all got a valid, random MAC,
the correct operational state and I can receive/sent traffic without
problems. I also tested with some other cdc_ether devices I have and did
not find any problems/regressions caused by the two general changes.

v3->v4:
* Forgot to remove unused variables, sorry about that (thanks David
Miller).

v2->v3:
* I had forgot to remove the random MAC generation from usbnet_cdc_bind()
(thanks Oliver).
* Rework logic in the ZTE bind-function a bit.

v1->v2:
* Only generate random MAC for ZTE devices (thanks Oliver Neukum).
* Set random MAC and do RX fixup for all ZTE devices that do not have a
product-entry, as the bogus MAC have been seen on devices with several
different PIDs/MAC addresses. In other words, it seems to be the default
behavior of ZTE CDC Ether devices (thanks Lars Melin).
Signed-off-by: NKristian Evensen <kristian.evensen@gmail.com>
Acked-by: NOliver Neukum <oneukum@suse.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The dependencies were impossible to handle preventing
drivers for CDC devices not which are not network drivers
from using the common parser.
Signed-off-by: NOliver Neukum <ONeukum@suse.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There are two generics functions phy_ethtool_{get|set}_link_ksettings,
so we can use them instead of defining the same code in the driver.
Signed-off-by: NPhilippe Reynes <tremyfr@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Some devices of the same type all export the same, random MAC address. This
behavior has been seen on the ZTE MF910, MF823 and MF831, and there are
probably more devices out there. Fix this by generating a valid random MAC
address if we read a random MAC from device.

Also, changed the memcpy() to ether_addr_copy(), as pointed out by
checkpatch.
Suggested-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NKristian Evensen <kristian.evensen@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

ethtool -i provides a driver version that is hard coded.
Export the same value via "modinfo".
Signed-off-by: NGrant Grundler <grundler@chromium.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The RTL8153-AD supports a persistent system specific MAC address.
This means a device plugged into two different systems with host side
support will show different (but persistent) MAC addresses.

This information for the system's persistent MAC address is burned in when
the system HW is built and available under \_SB.AMAC in the DSDT at runtime.

This technology is currently implemented in the Dell TB15 and WD15 Type-C
docks.  More information is available here:
http://www.dell.com/support/article/us/en/04/SLN301147Signed-off-by: NMario Limonciello <mario_limonciello@dell.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There is no conflict between the work_queue function and
rtl8152_set_speed(), so we don't have to cancel the delayed work in
rtl8152_set_speed().
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

After commit 90186af4 ("r8152: fix lockup when runtime PM is enabled"),
the autoresume wouldn't start the device before rtl8152_open() is finished.
Therefore, we don't have to reset the linking status before and after
autoresume. That is, one of netif_carrier_off() in rtl8152_open() could be
removed.
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In rtl_hw_phy_work_func_t(), the flag of PHY_RESET is set in
rtl_ops.hw_phy_cfg() and cleared in rtl8152_set_speed(). Therefore,
the rtl_phy_reset() is never run and is unnecessary.
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>