linux-toradex.git/drivers/net, branch v3.10.9

can: pcan_usb: fix wrong memcpy() bytes length

2013-08-20T15:43:03+00:00

commit 3c322a56b01695df15c70bfdc2d02e0ccd80654e upstream.

Fix possibly wrong memcpy() bytes length since some CAN records received from
PCAN-USB could define a DLC field in range [9..15].
In that case, the real DLC value MUST be used to move forward the record pointer
but, only 8 bytes max. MUST be copied into the data field of the struct
can_frame object of the skb given to the network core.

Signed-off-by: Stephane Grosjean 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

iwl4965: reset firmware after rfkill off

2013-08-20T15:43:03+00:00

commit 788f7a56fce1bcb2067b62b851a086fca48a0056 upstream.

Using rfkill switch can make firmware unstable, what cause various
Microcode errors and kernel warnings. Reseting firmware just after
rfkill off (radio on) helped with that.

Resolve:
https://bugzilla.redhat.com/show_bug.cgi?id=977053

Reported-and-tested-by: Justin Pearce 
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

iwl4965: set power mode early

2013-08-20T15:43:03+00:00

commit eca396d7a5bdcc1fd67b1b12f737c213ac78a6f4 upstream.

If device was put into a sleep and system was restarted or module
reloaded, we have to wake device up before sending other commands.
Otherwise it will fail to start with Microcode error.

Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: dvm: don't send BT_CONFIG on devices w/o Bluetooth

2013-08-12T01:35:26+00:00

commit 707aee401d2467baa785a697f40a6e2d9ee79ad5 upstream.

The BT_CONFIG command that is sent to the device during
startup will enable BT coex unless the module parameter
turns it off, but on devices without Bluetooth this may
cause problems, as reported in Redhat BZ 885407.

Fix this by sending the BT_CONFIG command only when the
device has Bluetooth.

Reviewed-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: set SSID bits for passive channels

2013-08-12T01:35:26+00:00

commit bb963c4a43eb5127eb0bbfa16c7a6a209b0af5db upstream.

Set SSID bitmap for direct scan even on passive channels,
for the passive-to-active feature. Without this patch only
the SSID from probe request template is sent on passive
channels, after passive-to-active switching, causing us to
not find all desired networks.

Remove the unused passive scan mask constant.

Reviewed-by: Emmanuel Grumbach 
Signed-off-by: David Spinadel 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

net/mlx4_core: VFs must ignore the enable_64b_cqe_eqe module param

2013-08-12T01:35:26+00:00

[ Upstream commit b30513202c6c14120f70b2e9aa1e97d47bbc2313 ]

Slaves get the 64B CQE/EQE state from QUERY_HCA, not from the module parameter.

If the parameter is set to zero, the slave outputs an incorrect/irrelevant
warning message that 64B CQEs/EQEs are supported but not enabled (even if the
hypervisor has enabled 64B CQEs/EQEs).

Signed-off-by: Jack Morgenstein 
Signed-off-by: Or Gerlitz 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net/mlx4_core: Don't give VFs MAC addresses which are derived from the PF MAC

2013-08-12T01:35:26+00:00

[ Upstream commit 0508ad646836007e6e6b62331eee7356844eac3d ]

If the user has not assigned a MAC address to a VM, then don't give it MAC which
is based on the PF one. The current derivation scheme is wrong and leads to VM
MAC collisions when the number of cards/hypervisors becomes big enough.

Instead, just give it zeros and let them figure out what to do with that.

Signed-off-by: Or Gerlitz 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

8139cp: Add dma_mapping_error checking

2013-08-12T01:35:26+00:00

[ Upstream commit cf3c4c03060b688cbc389ebc5065ebcce5653e96 ]

Self explanitory dma_mapping_error addition to the 8139 driver, based on this:
https://bugzilla.redhat.com/show_bug.cgi?id=947250

It showed several backtraces arising for dma_map_* usage without checking the
return code on the mapping.  Add the check and abort the rx/tx operation if its
failed.  Untested as I have no hardware and the reporter has wandered off, but
seems pretty straightforward.

Signed-off-by: Neil Horman 
CC: "David S. Miller" 
CC: Francois Romieu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

atl1c: use custom skb allocator

2013-08-12T01:35:26+00:00

[ Upstream commit 7b70176421993866e616f1cbc4d0dd4054f1bf78 ]

We had reports ( https://bugzilla.kernel.org/show_bug.cgi?id=54021 )
that using high order pages for skb allocations is problematic for atl1c

We do not know exactly what the problem is, but we suspect that crossing
4K pages is not well supported by this hardware.

Use a custom allocator, using page allocator and 2K fragments for
optimal stack behavior. We might make this allocator generic
in future kernels.

Signed-off-by: Eric Dumazet 
Cc: Luis Henriques 
Cc: Neil Horman 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

usbnet: do not pretend to support SG/TSO

2013-08-12T01:35:25+00:00

[ Upstream commit 20f0170377264e8449b6987041f0bcc4d746d3ed ]

usbnet doesn't support yet SG, so drivers should not advertise SG or TSO
capabilities, as they allow TCP stack to build large TSO packets that
need to be linearized and might use order-5 pages.

This adds an extra copy overhead and possible allocation failures.

Current code ignore skb_linearize() return code so crashes are even
possible.

Best is to not pretend SG/TSO is supported, and add this again when/if
usbnet really supports SG for devices who could get a performance gain.

Based on a prior patch from Freddy Xin 

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman