linux-stable.git/drivers/net, branch v4.1.6

ath10k: fix qca61x4 hw2.1 support

2015-08-17T03:52:14+00:00

commit 11a002efbaa7fbd9f6e616695ab42aa9f1caf060 upstream.

During initialization firmware does some sort of
memory switch between DRAM and IRAM. If
configuration value for bank switching isn't
correct device crashes during init.

The new value prevents firmware 11.0.0.302 (and
possibly others) for qca61x4 hw2.1 from crashing
during init.

Signed-off-by: Michal Kazior 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: pcie: prepare the device before accessing it

2015-08-10T19:21:55+00:00

commit f9e5554cd8ca1d1212ec922755b397a20f737923 upstream.

For 8000 series, we need to access the device to know what
firmware to load. Before we do so, we need to prepare the
device otherwise we might not be able to access the
hardware.

Fixes: c278754a21e6 ("iwlwifi: mvm: support family 8000 B2/C steps")
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: nvm: remove mac address byte swapping in 8000 family

2015-08-10T19:21:55+00:00

commit be88a1ada9b97bb016196b7f4a1fc2fe2f798529 upstream.

This fixes the byte order copying in the MAO (Mac Override
Section) section from the PNVM, as the byte swapping is not
required anymore in the 8000 family. Due to the byte
swapping, the driver was reporting an incorrect MAC
adddress.

Signed-off-by: Liad Kaufman 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: fix antenna selection when BT is active

2015-08-10T19:21:55+00:00

commit 923a8c1d8069104726bde55c37cec66324ccc328 upstream.

When BT is active, we want to avoid the shared antenna for
management frame to make sure we don't disturb BT. There
was a bug in that code because it chose the antenna
BIT(ANT_A) where ANT_A is already a bitmap (0x1). This
means that the antenna chosen in the end was ANT_B.
While this is not optimal on devices with 2 antennas (it'd
disturb BT), it is critical on single antenna devices like
3160 which couldn't connect at all when BT was active.

This fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=97181

Fixes: 34c8b24ff284 ("iwlwifi: mvm: BT Coex - avoid the shared antenna for management frames")
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

can: mcp251x: fix resume when device is down

2015-08-10T19:21:51+00:00

commit 25b401c1816ae64bcc5dcb1d39ab41812522a0ce upstream.

If a valid power regulator or a dummy regulator is used (which
happens to be the case when no regulator is specified), restart_work
is queued no matter whether the device was running or not at suspend
time. Since work queues get initialized in the ndo_open callback,
resuming leads to a NULL pointer exception.

Reverse exactly the steps executed at suspend time:
- Enable the power regulator in any case
- Enable the transceiver regulator if the device was running, even in
  case we have a power regulator
- Queue restart_work only in case the device was running

Fixes: bf66f3736a94 ("can: mcp251x: Move to threaded interrupts instead of workqueues.")
Signed-off-by: Stefan Agner 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman

can: rcar_can: print signed IRQ #

2015-08-10T19:21:51+00:00

commit c1a4c87b06fa564d6e2760a12d4e5a09badc684b upstream.

Printing IRQ # using "%x" and "%u" unsigned formats isn't quite correct as
'ndev->irq' is of  type *int*, so  the "%d" format  needs to be used instead.

While fixing this, beautify the dev_info() message in rcar_can_probe() a bit.

Fixes: fd1159318e55 ("can: add Renesas R-Car CAN driver")
Signed-off-by: Sergei Shtylyov 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman

can: c_can: Fix default pinmux glitch at init

2015-08-10T19:21:51+00:00

commit 033365191136c97f88c81b7bd0011414db28bb4e upstream.

The previous change 3973c526ae9c (net: can: c_can: Disable pins when CAN
interface is down) causes a slight glitch on the pinctrl settings when used.
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
the device core will automatically set the default pins. This causes the pins
to be momentarily set to the default and then to the sleep state in
register_c_can_dev(). By adding an optional "enable" state, boards can set the
default pin state to be disabled and avoid the glitch when the switch from
default to sleep first occurs. If the "enable" state is not available
c_can_pinctrl_select_state() falls back to using the "default" pinctrl state.

[Roger Q] - Forward port to v4.2 and use pinctrl_get_select().

Signed-off-by: J.D. Schroeder 
Signed-off-by: Roger Quadros 
Reviewed-by: Grygorii Strashko 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman

can: rcar_can: fix IRQ check

2015-08-10T19:21:51+00:00

commit 5e63e6baa159fa8c787cf783dbf3d77fbea97331 upstream.

rcar_can_probe() regards 0 as a wrong IRQ #, despite platform_get_irq() that it
calls returns negative error code in that case. This leads to the following
being printed to the console when attempting to open the device:

error requesting interrupt fffffffa

because  rcar_can_open() calls request_irq() with a negative IRQ #, and that
function naturally fails with -EINVAL.

Check for the negative error codes instead and propagate them upstream instead
of just returning -ENODEV.

Fixes: fd1159318e55 ("can: add Renesas R-Car CAN driver")
Signed-off-by: Sergei Shtylyov 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman

can: replace timestamp as unique skb attribute

2015-08-10T19:21:51+00:00

commit d3b58c47d330de8c29898fe9746f7530408f8a59 upstream.

Commit 514ac99c64b "can: fix multiple delivery of a single CAN frame for
overlapping CAN filters" requires the skb->tstamp to be set to check for
identical CAN skbs.

Without timestamping to be required by user space applications this timestamp
was not generated which lead to commit 36c01245eb8 "can: fix loss of CAN frames
in raw_rcv" - which forces the timestamp to be set in all CAN related skbuffs
by introducing several __net_timestamp() calls.

This forces e.g. out of tree drivers which are not using alloc_can{,fd}_skb()
to add __net_timestamp() after skbuff creation to prevent the frame loss fixed
in mainline Linux.

This patch removes the timestamp dependency and uses an atomic counter to
create an unique identifier together with the skbuff pointer.

Btw: the new skbcnt element introduced in struct can_skb_priv has to be
initialized with zero in out-of-tree drivers which are not using
alloc_can{,fd}_skb() too.

Signed-off-by: Oliver Hartkopp 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman

e1000e: Cleanup handling of VLAN_HLEN as a part of max frame size

2015-08-03T16:29:16+00:00

commit 8084b86dcfbc4b4822868c1dbdb429b5c08154e2 upstream.

When the VLAN_HLEN was added to the calculation for the maximum frame size
there seems to have been a number of issues added to the driver.

The first issue is that in some cases the maximum frame size for a device
never really reached the actual maximum frame size as the VLAN header
length was not included the calculation for that value.  As a result some
parts only supported a maximum frame size of either 1496 in the case of
parts that didn't support jumbo frames, and 8996 in the case of the parts
that do.

The second issue is the fact that there were several checks that weren't
updated so as a result setting an MTU of 1500 was treated as enabling jumbo
frames as the calculated value was 1522 instead of 1518.  I have addressed
those by replacing ETH_FRAME_LEN with VLAN_ETH_FRAME_LEN where appropriate.

The final issue was the fact that lowering the MTU below 1500 would cause
the driver to allocate 2K buffers for the rings.  This is an old issue that
was fixed several years ago in igb/ixgbe and I am addressing now by just
replacing == with a <= so that we always just round up to 1522 for anything
that isn't a jumbo frame.

Fixes: c751a3d58cf2d ("e1000e: Correctly include VLAN_HLEN when changing interface MTU")
Signed-off-by: Alexander Duyck 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Greg Kroah-Hartman