Commit 84ebc10294a3d7be4c66f51070b7aedbaa24de9b (USB: remove CONFIG_USB_SUSPEND option) failed to remove all of the usages of USB_SUSPEND throughout the kernel. This patch (as1677) removes the remaining instances of that symbol. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some drivers (sierra_net) need the status interrupt URB active even when the device is closed, because they receive custom indications from firmware. Add functions to refcount the status interrupt URB submit/kill operation so that sub-drivers and the generic driver don't fight over whether the status interrupt URB is active or not. A sub-driver can call usbnet_status_start() at any time, but the URB is only submitted the first time the function is called. Likewise, when the sub-driver is done with the URB, it calls usbnet_status_stop() but the URB is only killed when all users have stopped it. The URB is still killed and re-submitted for suspend/resume, as before, with the same refcount it had at suspend. Signed-off-by: Dan Williams <dcbw@redhat.com> Acked-by: Oliver Neukum <oliver@neukum.org> Signed-off-by: David S. Miller <davem@davemloft.net>
The link change is detected via the interrupt pipe, and bulk pipes are responsible for transfering packets, so it is reasonable to stop bulk transfer after link is reported as off. Two adavantages may be obtained with stopping bulk transfer after link becomes off: - USB bus bandwidth is saved(USB bus is shared bus except for USB3.0), for example, lots of 'IN' token packets and 'NYET' handshake packets is transfered on 2.0 bus. - probabaly power might be saved for usb host controller since cancelling bulk transfer may disable the asynchronous schedule of host controller. With this patch, when link becomes off, about ~10% performance boost can be found on bulk transfer of anther usb device which is attached to same bus with the usbnet device, see below test on next-20130410: - read from usb mass storage(Sandisk Extreme USB 3.0) on pandaboard with below command after unplugging ethernet cable: dd if=/dev/sda iflag=direct of=/dev/null bs=1M count=800 - without the patch 1, 838860800 bytes (839 MB) copied, 36.2216 s, 23.2 MB/s 2, 838860800 bytes (839 MB) copied, 35.8368 s, 23.4 MB/s 3, 838860800 bytes (839 MB) copied, 35.823 s, 23.4 MB/s 4, 838860800 bytes (839 MB) copied, 35.937 s, 23.3 MB/s 5, 838860800 bytes (839 MB) copied, 35.7365 s, 23.5 MB/s average: 23.6MB/s - with the patch 1, 838860800 bytes (839 MB) copied, 32.3817 s, 25.9 MB/s 2, 838860800 bytes (839 MB) copied, 31.7389 s, 26.4 MB/s 3, 838860800 bytes (839 MB) copied, 32.438 s, 25.9 MB/s 4, 838860800 bytes (839 MB) copied, 32.5492 s, 25.8 MB/s 5, 838860800 bytes (839 MB) copied, 31.6178 s, 26.5 MB/s average: 26.1MB/s Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Use usbnet_link_change to handle link change centrally. Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
This patch introduces the API of usbnet_link_change, so that usbnet can handle link change centrally, which may help to implement killing traffic URBs for saving USB bus bandwidth and host controller power. Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Conflicts: drivers/net/ethernet/intel/e1000e/ethtool.c drivers/net/vmxnet3/vmxnet3_drv.c drivers/net/wireless/iwlwifi/dvm/tx.c net/ipv6/route.c The ipv6 route.c conflict is simple, just ignore the 'net' side change as we fixed the same problem in 'net-next' by eliminating cached neighbours from ipv6 routes. The e1000e conflict is an addition of a new statistic in the ethtool code, trivial. The vmxnet3 conflict is about one change in 'net' removing a guarding conditional, whilst in 'net-next' we had a netdev_info() conversion. The iwlwifi conflict is dealing with a WARN_ON() conversion in 'net-next' vs. a revert happening in 'net'. Signed-off-by: David S. Miller <davem@davemloft.net>
alloc failures already get standardized OOM messages and a dump_stack. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
It is normal for minidrivers accumulating frames to return NULL from their tx_fixup function. We do not want to count this as a drop, or log any debug messages. A different exit path is therefore chosen for such drivers, skipping the debug message and the tx_dropped increment. The test for accumulating drivers was however completely bogus, making the exit path selection depend on whether the user had enabled tx_err logging or not. This would arbitrarily mess up accounting for both accumulating and non-accumulating minidrivers, and would result in unwanted debug messages for the accumulating drivers. Fix by testing for FLAG_MULTI_PACKET instead, which probably was the intention from the beginning. This usage match the documented behaviour of this flag: Indicates to usbnet, that USB driver accumulates multiple IP packets. Affects statistic (counters) and short packet handling. Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: David S. Miller <davem@davemloft.net>
A device sending 0 length frames as fast as it can has been observed killing the host system due to the resulting memory pressure. Temporarily disable RX skb allocation and URB submission when the current error ratio is high, preventing us from trying to allocate an infinite number of skbs. Reenable as soon as we are finished processing the done queue, allowing the device to continue working after short error bursts. Signed-off-by: Bjørn Mork <bjorn@mork.no> Acked-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: David S. Miller <davem@davemloft.net>
We do have some USB net devices, which cannot do ARP. so we can introduce a new flag FLAG_NOARP, then client drivers can easily handle this kind of devices Signed-off-by: Wei Shuai <cpuwolf@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>