linux-toradex.git/drivers/net/usb/usbnet.c, branch v3.9.4 Linux kernel for Apalis and Colibri modules Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net 2013-02-05T19:12:20+00:00 David S. Miller davem@davemloft.net 2013-02-05T19:12:20+00:00 188d1f76d0dd3715ceeadfa31376867c3395eb41 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> 
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>
drivers: net: usb: Remove unnecessary alloc/OOM messages 2013-02-04T18:22:34+00:00 Joe Perches joe@perches.com 2013-02-03T17:28:11+00:00 38673c8218a6bcaac97b0243089e33617e28f43f 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> 
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>
net: usbnet: fix tx_dropped statistics 2013-02-04T18:07:31+00:00 Bjørn Mork bjorn@mork.no 2013-01-31T08:36:05+00:00 bf414b369f158bb527f9f29174ada815f961b44c 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> 
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>
net: usbnet: prevent buggy devices from killing us 2013-01-30T22:35:44+00:00 Bjørn Mork bjorn@mork.no 2013-01-28T23:51:28+00:00 70c37bf97f2a91accba76080db69144f3b69f736 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> 
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>
usbnet: add new flag FLAG_NOARP for usb net devices 2013-01-21T19:24:37+00:00 Wei Shuai cpuwolf@gmail.com 2013-01-21T06:00:31+00:00 6509141f9c2ba74df6cc72ec35cd1865276ae3a4 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> 
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>
usbnet: generic manage_power() 2012-12-19T20:46:40+00:00 Oliver Neukum oliver@neukum.org 2012-12-18T04:45:52+00:00 2dd7c8cf29769f6b66f26b501db2364640c2c9d0 Centralise common code for manage_power() in usbnet by making a generic simple implementation Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: David S. Miller <davem@davemloft.net> 
Centralise common code for manage_power() in usbnet
by making a generic simple implementation

Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
usbnet: handle PM failure gracefully 2012-12-19T20:46:40+00:00 Oliver Neukum oliver@neukum.org 2012-12-18T04:45:29+00:00 a1c088e01b71d90852b0df5a77cdae46bd0e0c05 If a device fails to do remote wakeup, this is no reason to abort an open totally. This patch just continues without runtime PM. Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: David S. Miller <davem@davemloft.net> 
If a device fails to do remote wakeup, this is no reason
to abort an open totally. This patch just continues without
runtime PM.

Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net 2012-11-10T23:32:51+00:00 David S. Miller davem@davemloft.net 2012-11-10T23:32:51+00:00 d4185bbf62a5d8d777ee445db1581beb17882a07 Conflicts: drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c Minor conflict between the BCM_CNIC define removal in net-next and a bug fix added to net. Based upon a conflict resolution patch posted by Stephen Rothwell. Signed-off-by: David S. Miller <davem@davemloft.net> 
Conflicts:
	drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c

Minor conflict between the BCM_CNIC define removal in net-next
and a bug fix added to net.  Based upon a conflict resolution
patch posted by Stephen Rothwell.

Signed-off-by: David S. Miller <davem@davemloft.net>
usbnet: ratelimit kevent may have been dropped warnings 2012-11-09T21:59:32+00:00 Steve Glendinning steve.glendinning@shawell.net 2012-11-08T06:26:21+00:00 9532021da6da48351ce48a079c673df8e3930b4a when something goes wrong, a flood of these messages can be generated by usbnet (thousands per second). This doesn't generally *help* the condition so this patch ratelimits the rate of their generation. There's an underlying problem in usbnet's kevent deferral mechanism which needs fixing, specifically that events *can* get dropped and not handled. This patch doesn't address this, but just mitigates fallout caused by the current implemention. Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net> Signed-off-by: David S. Miller <davem@davemloft.net> 
when something goes wrong, a flood of these messages can be
generated by usbnet (thousands per second).  This doesn't
generally *help* the condition so this patch ratelimits the
rate of their generation.

There's an underlying problem in usbnet's kevent deferral
mechanism which needs fixing, specifically that events *can*
get dropped and not handled.  This patch doesn't address this,
but just mitigates fallout caused by the current implemention.

Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
usbnet: runtime wake up device before calling usbnet_{read|write}_cmd 2012-11-07T08:53:38+00:00 Ming Lei ming.lei@canonical.com 2012-11-06T04:53:08+00:00 6f0a0986e328dd61610d898a09c9f4aa960ae64a This patch gets the runtime PM reference count before calling usbnet_{read|write}_cmd, and puts it after completion of the usbnet_{read|write}_cmd, so that the usb control message can always be sent to one active device in the non-PM context. Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
This patch gets the runtime PM reference count before calling
usbnet_{read|write}_cmd, and puts it after completion of the
usbnet_{read|write}_cmd, so that the usb control message can always
be sent to one active device in the non-PM context.

Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>