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

ath10k: set CTS protection VDEV param only if VDEV is up

2017-11-30T08:37:26+00:00

[ Upstream commit 7cfe0455ee1218add152e986b89b4bb8dbeafcdd ]

The cts protection vdev parameter, in new QCA9377 TF2.0 firmware,
requires bss peer to be created for the STATION vdev type.
bss peer is being allocated by the firmware after vdev_start/_up commands.
mac80211 may call the cts protection setup at any time, so the
we needs to track the situation and defer the cts configuration
to prevent firmware asserts, like below:

[00]: 0x05020001 0x000015B3 0x0099ACE2 0x00955B31
[04]: 0x0099ACE2 0x00060730 0x00000004 0x00000000
[08]: 0x0044C754 0x00412C10 0x00000000 0x00409C54
[12]: 0x00000009 0x00000000 0x00952F6C 0x00952F77
[16]: 0x00952CC4 0x00910712 0x00000000 0x00000000
[20]: 0x4099ACE2 0x0040E858 0x00421254 0x004127F4
[24]: 0x8099B9B2 0x0040E8B8 0x00000000 0xC099ACE2
[28]: 0x800B75CB 0x0040E8F8 0x00000007 0x00005008
[32]: 0x809B048A 0x0040E958 0x00000010 0x00433B10
[36]: 0x809AFBBC 0x0040E9A8 0x0042BB74 0x0042BBBC
[40]: 0x8091D252 0x0040E9C8 0x0042BBBC 0x00000001
[44]: 0x809FFA45 0x0040EA78 0x0043D3E4 0x0042C2C8
[48]: 0x809FCEF4 0x0040EA98 0x0043D3E4 0x00000001
[52]: 0x80911210 0x0040EAE8 0x00000010 0x004041D0
[56]: 0x80911154 0x0040EB28 0x00400000 0x00000000

Signed-off-by: Bartosz Markowski 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

ath10k: fix potential memory leak in ath10k_wmi_tlv_op_pull_fw_stats()

2017-11-30T08:37:26+00:00

[ Upstream commit 097e46d2ae90265d1afe141ba6208ba598b79e01 ]

ath10k_wmi_tlv_op_pull_fw_stats() uses tb = ath10k_wmi_tlv_parse_alloc(...)
function, which allocates memory. If any of the three error-paths are
taken, this tb needs to be freed.

Signed-off-by: Christian Lamparter 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

ath10k: ignore configuring the incorrect board_id

2017-11-30T08:37:26+00:00

[ Upstream commit d2e202c06ca42d353d95df12437740921a6d05b5 ]

With command to get board_id from otp, in the case of following

  boot get otp board id result 0x00000000 board_id 0 chip_id 0
  boot using board name 'bus=pci,bmi-chip-id=0,bmi-board-id=0"
  ...
  failed to fetch board data for bus=pci,bmi-chip-id=0,bmi-board-id=0 from
  ath10k/QCA6174/hw3.0/board-2.bin

The invalid board_id=0 will be used as index to search in the board-2.bin.

Ignore the case with board_id=0, as it means the otp is not carrying
the board id information.

Signed-off-by: Ryan Hsu 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

ath10k: fix incorrect txpower set by P2P_DEVICE interface

2017-11-30T08:37:26+00:00

[ Upstream commit 88407beb1b1462f706a1950a355fd086e1c450b6 ]

Ath10k reports the phy capability that supports P2P_DEVICE interface.

When we use the P2P supported wpa_supplicant to start connection, it'll
create two interfaces, one is wlan0 (vdev_id=0) and one is P2P_DEVICE
p2p-dev-wlan0 which is for p2p control channel (vdev_id=1).

	ath10k_pci mac vdev create 0 (add interface) type 2 subtype 0
	ath10k_add_interface: vdev_id: 0, txpower: 0, bss_power: 0
	...
	ath10k_pci mac vdev create 1 (add interface) type 2 subtype 1
	ath10k_add_interface: vdev_id: 1, txpower: 0, bss_power: 0

And the txpower in per vif bss_conf will only be set to valid tx power when
the interface is assigned with channel_ctx.

But this P2P_DEVICE interface will never be used for any connection, so
that the uninitialized bss_conf.txpower=0 is assinged to the
arvif->txpower when interface created.

Since the txpower configuration is firmware per physical interface.
So the smallest txpower of all vifs will be the one limit the tx power
of the physical device, that causing the low txpower issue on other
active interfaces.

	wlan0: Limiting TX power to 21 (24 - 3) dBm
	ath10k_pci mac vdev_id 0 txpower 21
	ath10k_mac_txpower_recalc: vdev_id: 1, txpower: 0
	ath10k_mac_txpower_recalc: vdev_id: 0, txpower: 21
	ath10k_pci mac txpower 0

This issue only happens when we use the wpa_supplicant that supports
P2P or if we use the iw tool to create the control P2P_DEVICE interface.

Signed-off-by: Ryan Hsu 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

net: 3com: typhoon: typhoon_init_one: fix incorrect return values

2017-11-30T08:37:26+00:00

[ Upstream commit 107fded7bf616ad6f46823d98b8ed6405d7adf2d ]

In a few cases the err-variable is not set to a negative error code if a
function call in typhoon_init_one() fails and thus 0 is returned
instead.
It may be better to set err to the appropriate negative error
code before returning.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188841

Reported-by: Pan Bian 
Signed-off-by: Thomas Preisner 
Signed-off-by: Milan Stephan 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

net: 3com: typhoon: typhoon_init_one: make return values more specific

2017-11-30T08:37:26+00:00

[ Upstream commit 6b6bbb5922a4b1d4b58125a572da91010295fba3 ]

In some cases the return value of a failing function is not being used
and the function typhoon_init_one() returns another negative error code
instead.

Signed-off-by: Thomas Preisner 
Signed-off-by: Milan Stephan 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

e1000e: Separate signaling for link check/link up

2017-11-30T08:37:25+00:00

commit 19110cfbb34d4af0cdfe14cd243f3b09dc95b013 upstream.

Lennart reported the following race condition:

\ e1000_watchdog_task
    \ e1000e_has_link
        \ hw->mac.ops.check_for_link() === e1000e_check_for_copper_link
            /* link is up */
            mac->get_link_status = false;

                            /* interrupt */
                            \ e1000_msix_other
                                hw->mac.get_link_status = true;

        link_active = !hw->mac.get_link_status
        /* link_active is false, wrongly */

This problem arises because the single flag get_link_status is used to
signal two different states: link status needs checking and link status is
down.

Avoid the problem by using the return value of .check_for_link to signal
the link status to e1000e_has_link().

Reported-by: Lennart Sorensen 
Signed-off-by: Benjamin Poirier 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Amit Pundir 
Signed-off-by: Greg Kroah-Hartman

e1000e: Fix return value test

2017-11-30T08:37:25+00:00

commit d3509f8bc7b0560044c15f0e3ecfde1d9af757a6 upstream.

All the helpers return -E1000_ERR_PHY.

Signed-off-by: Benjamin Poirier 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Amit Pundir 
Signed-off-by: Greg Kroah-Hartman

e1000e: Fix error path in link detection

2017-11-30T08:37:25+00:00

commit c4c40e51f9c32c6dd8adf606624c930a1c4d9bbb upstream.

In case of error from e1e_rphy(), the loop will exit early and "success"
will be set to true erroneously.

Signed-off-by: Benjamin Poirier 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Amit Pundir 
Signed-off-by: Greg Kroah-Hartman

ixgbe: Fix skb list corruption on Power systems

2017-11-30T08:37:24+00:00

commit 0a9a17e3bb4564caf4bfe2a6783ae1287667d188 upstream.

This patch fixes an issue seen on Power systems with ixgbe which results
in skb list corruption and an eventual kernel oops. The following is what
was observed:

CPU 1                                   CPU2
============================            ============================
1: ixgbe_xmit_frame_ring                ixgbe_clean_tx_irq
2:  first->skb = skb                     eop_desc = tx_buffer->next_to_watch
3:  ixgbe_tx_map                         read_barrier_depends()
4:   wmb                                 check adapter written status bit
5:   first->next_to_watch = tx_desc      napi_consume_skb(tx_buffer->skb ..);
6:   writel(i, tx_ring->tail);

The read_barrier_depends is insufficient to ensure that tx_buffer->skb does not
get loaded prior to tx_buffer->next_to_watch, which then results in loading
a stale skb pointer. This patch replaces the read_barrier_depends with
smp_rmb to ensure loads are ordered with respect to the load of
tx_buffer->next_to_watch.

Signed-off-by: Brian King 
Acked-by: Jesse Brandeburg 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Greg Kroah-Hartman